当前位置：首页 > 文章列表 > 文章 > java教程 > 自定义Java异常类，添加错误码及RuntimeException继承

自定义Java异常类，添加错误码及RuntimeException继承

2026-03-25 19:03:30 0浏览收藏

本文深入讲解了如何科学设计自定义Java业务异常类：通过继承RuntimeException实现非强制捕获，避免繁琐的try-catch或throws声明；采用private final int errorCode字段确保错误码稳定不可变，并提供标准构造与getter；谨慎权衡是否重写fillInStackTrace以平衡排查能力与性能；最后强调在Spring中必须配合@RestControllerAdvice和@ExceptionHandler显式配置全局处理，将错误码安全、规范地透传至前端，构建健壮可维护的统一异常响应体系——帮你避开从定义到落地的几乎所有典型坑。

如何自定义Java异常类_继承RuntimeException并添加错误码

为什么继承 RuntimeException 而不是 Exception

因为你要的是「不强制捕获」的异常，比如参数校验失败、业务规则违反这类程序运行中可预期但不该被层层 try-catch 的问题。RuntimeException 及其子类属于 unchecked exception，调用方无需声明或处理，代码更干净；而继承 Exception 会逼迫所有上层方法加 throws 或包在 try 里，实际开发中几乎没人这么干——除非你真想强制调用方处理（比如 IO 异常），但错误码场景基本不需要。

常见错误现象：javac 报错 “unreported exception XxxException; must be caught or declared to be thrown”，就是不小心继承了 Exception 却没处理它。

确认父类是 RuntimeException，不是 Exception 或 Throwable
别在构造函数里漏掉 super(message) 或 super(message, cause)，否则堆栈跟踪会丢根因
IDE 自动生成构造函数时注意删掉无参构造（除非你明确需要），避免误用

如何添加错误码字段并保证不可变

错误码本质是业务标识，必须稳定、不可变、能直接映射到文档或配置。用 final int 是最简单可靠的方式，别用 String 编码（难比对）、也别用静态常量池（耦合重、难扩展）。

使用场景：统一异常处理器（如 Spring 的 @ControllerAdvice）根据 errorCode 返回不同 HTTP 状态码或响应体；前端根据码值做差异化提示。

字段声明为 private final int errorCode，只在构造时赋值
提供 getter 方法 getErrorCode()，不要 setter
构造函数必须接收 errorCode，且优先级高于 message：先定码，再定提示

示例：

public class BizException extends RuntimeException {
    private final int errorCode;
    public BizException(int errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }
    public int getErrorCode() { return errorCode; }
}

要不要重写 fillInStackTrace

要，但只在确定不需要完整堆栈时才关。默认行为会收集从抛出点到当前的全部栈帧，对日志友好，但有性能开销（尤其高频校验场景）。关闭后异常对象创建快 3–5 倍，但排查问题时看不到“谁调的谁”。

容易踩的坑：盲目重写成 return this 导致所有同类异常堆栈都一样，根本分不清触发路径。

如果错误码已足够定位问题（比如 USER_NOT_FOUND(1001) 对应固定接口），且性能敏感，可关闭：
```
@Override
public synchronized Throwable fillInStackTrace() {
    return this;
}
```
否则保留默认行为——大多数内部服务没必要动它
别只重写部分构造函数，所有构造入口都要一致处理，否则行为不统一