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 Paymen
tFailedException(String message) {
        super(message);
    }

    public PaymentFailedException(String message, Throwable cause) {
        super(message, cause);
    }

    public PaymentFailedException(Throwable cause) {
        super(cause);
    }
}

原因：catch 块中抛出新异常时经常需要包装原异常（cause），而日志或框架（如 Spring）在序列化/打印堆栈时依赖这些构造函数。缺任何一个都可能导致 NullPointerException 或丢失原始异常信息。

要不要加 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 异常才触发回滚）