Java自定义异常类怎么用

golang学习网今天将给大家带来《Java自定义异常类方法详解》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

必须继承Exception或RuntimeException，因JVM仅识别Throwable子类异常；继承Exception强制调用方处理，适合业务可控错误；继承RuntimeException则无需声明，适用于程序逻辑错误。

为什么必须继承 Exception 或 RuntimeException

Java 的异常体系强制要求自定义异常类必须是 Throwable 的子类，而实际开发中几乎总是选择继承 Exception（受检异常）或 RuntimeException（非受检异常）。不这样做会导致编译失败——比如直接继承 Object 写个 MyException，连 throw new MyException() 都过不了编译。

关键区别在于：继承 Exception 会让调用方**必须处理**（try/catch 或 throws），适合业务中明确需要强制干预的错误（如支付金额超限、用户未实名）；继承 RuntimeException 则无需强制声明，适合程序逻辑错误或不可恢复的意外（如参数为 null 且不该发生）。

• 不要试图绕过继承机制，用包装或代理方式模拟异常行为——JVM 不认，catch 不会捕获
• 如果想让异常既可检查又可运行时切换，得靠两个独立类，不能靠“动态继承”
• IDE 自动生成的构造函数常漏掉 cause 参数，导致嵌套异常信息丢失

super(message) 和 super(message, cause) 怎么选

绝大多数自定义异常类至少要提供带 String 参数的构造方法，否则 new MyBusinessException("余额不足") 会报错。但仅此不够——当你的异常是由另一个异常触发的（比如数据库操作失败引发业务异常），必须把原始异常作为 cause 传进去，否则堆栈里看不到底层根因。

推荐构造函数组合：

• public MyException(String message) → 调用 super(message)
• public MyException(String message, Throwable cause) → 调用 super(message, cause)
• 可选：public MyException(Throwable cause) → 调用 super(cause)，方便包装已有异常

public class InsufficientBalanceException extends Exception {
    public InsufficientBalanceException(String message) {
        super(message);
    }
    public InsufficientBalanceException(String message, Throwable cause) {
        super(message, cause);
    }
}

要不要重写 getMessage() 或 toString()

一般不用。父类 Exception 已经实现了清晰的 getMessage()（返回构造时传入的 message）和 toString()（含类名 + message）。除非你有强定制需求，比如所有业务异常必须前置固定前缀，才考虑重写：

public class OrderException extends Exception {
    public OrderException(String message) {
        super("[订单系统] " + message);
    }
    // 不建议重写 getMessage() 去拼接，容易和 cause.getMessage() 混淆
}

更安全的做法是：在日志打印时统一加前缀，而不是污染异常对象本身。重写 toString() 尤其危险——很多监控系统、序列化工具依赖它的默认格式，改了可能导致告警解析失败。

• 日志框架（如 Logback）可通过 %X{traceId} 等 MDC 字段补充上下文，比改异常更灵活
• 如果真要丰富异常信息，优先用额外字段 + getter（如 getOrderId()），而不是覆盖核心方法

序列化问题：serialVersionUID 必须显式声明吗

必须。自定义异常类默认实现 Serializable，一旦涉及远程调用（Dubbo、RMI）、缓存（Redis 存异常对象）、或集群间传递，没有显式 serialVersionUID 会导致 InvalidClassException：「local class incompatible」。

原因：JVM 自动生成的 UID 依赖类结构细节（方法签名、字段顺序等），微小改动就会变，而异常类常随业务迭代频繁修改字段（比如加个 errorCode int 字段）。

• 固定值推荐用 1L 或时间戳（如 20240501L），避免用 IDE 自动生成的长随机数
• 如果异常类确定永不序列化（如纯内存校验异常），可加 private static final long serialVersionUID = 0L; 并注释说明
• 子类必须声明自己的 serialVersionUID，不会继承父类的

public class PaymentRejectedException extends RuntimeException {
    private static final long serialVersionUID = 20240501L;
    private final String transactionId;

    public PaymentRejectedException(String message, String transactionId) {
        super(message);
        this.transactionId = transactionId;
    }

    public String getTransactionId() {
        return transactionId;
    }
}

实际项目中最容易被忽略的是 cause 的透传和 serialVersionUID 的维护——前者让问题排查断链，后者让上线后出现莫名其妙的反序列化失败。

理论要掌握，实操不能落！以上关于《Java自定义异常类怎么用》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！