登录
首页 >  文章 >  java教程

Java自定义异常类怎么用

时间:2026-01-19 13:36:36 494浏览 收藏

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

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

在Java中如何自定义异常类_JavaException扩展解析

为什么必须继承 ExceptionRuntimeException

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学习网公众号吧!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>