Java自定义异常需根据checked/unchecked需求选择继承Exception或RuntimeException；必须提供4个标准构造函数；建议显式声明serialVersionUID；异常名须以Exception结尾，避免日志泄露敏感信息。
Java 中自定义异常类不是必须继承 Exception，而是取决于你想要的是**检查型异常（checked）**还是**非检查型异常（unchecked）**：继承 Exception（或其子类，但非 RuntimeException）得到 checked 异常；继承 RuntimeException 得到 unchecked 异常。
继承 Exception 还是 RuntimeException？
这是最关键的取舍点，直接影响调用方是否被强制处理：
-
Exception及其子类（除RuntimeException外）：编译器强制要求try-catch或throws，适合业务中「预期可能出错且调用方必须决策」的场景，比如InsufficientBalanceException -
RuntimeException及其子类：无需显式处理，适合「程序逻辑错误或不应恢复的异常」，比如InvalidOrderStatusException（状态非法通常是代码 bug，不是正常业务分支） - 别直接继承
Throwable——会绕过 Java 异常分类机制，导致行为不可预测
必须实现的构造函数有哪些？
标准做法是提供以下 4 个构造函数，覆盖所有常见调用方式：
public class PaymentFailedException extends Exception {
public PaymentFailedException() {
super();
}
public PaymentFailedException(String message) {
super(message);
}
public PaymentFailedException(String message, Throwable cause) {
super(message, cause);
}
public PaymentFailedException(Throwable cause) {
super(cause);
}
}
原因：catch 块中抛出新异常时经常需要包装原异常（cause），而日志或框架（如 Spring）在序列化/打印堆栈时依赖这些构造函数。缺任何一个都可能导致 NullPointerException 或丢失原始异常信息。
立即学习“Java免费学习笔记（深入）”；
要不要加 serialVersionUID？
要，尤其是异常类可能被序列化（例如在分布式 RPC、RMI 或某些消息队列场景中）：
- 不加
serialVersionUID：JVM 自动生成，但只要类结构稍有改动（比如新增字段），反序列化就会失败，报InvalidClassException - 显式声明：值可固定为
1L或用 IDE 自动生成，确保兼容性 - 如果确定该异常**永远不会跨 JVM 传输**（纯本地服务内使用），可省略，但建议统一加上，避免后续扩展踩坑
实际使用中容易忽略的细节
自定义异常真正落地时，最常被跳过的其实是语义清晰和上下文携带：
- 异常名必须以
Exception结尾（如UserNotFoundException），否则违反 Java 约定，IDE 和静态检查工具（如 Sonar）会警告 - 不要在异常消息里拼接敏感数据（如密码、token），避免日志泄露；可用占位符 +
toString()或专用字段存储 ID、订单号等安全上下文 - 如果需要传递额外信息（如错误码、HTTP 状态码），建议添加
private final int errorCode;字段，并提供 getter，而不是靠解析getMessage() - Spring 项目中，若用于 @ControllerAdvice 全局捕获，记得确认异常类没被 AOP 代理拦截（比如被
@Transactional包裹时，unchecked 异常才触发回滚）
