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

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

为什么继承 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 {<br>    private final int errorCode;<br>    public BizException(int errorCode, String message) {<br>        super(message);<br>        this.errorCode = errorCode;<br>    }<br>    public int getErrorCode() { return errorCode; }<br>}

要不要重写 fillInStackTrace

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

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

• 如果错误码已足够定位问题（比如 USER_NOT_FOUND(1001) 对应固定接口），且性能敏感，可关闭：

  @Override<br>public synchronized Throwable fillInStackTrace() {<br>    return this;<br>}

• 否则保留默认行为——大多数内部服务没必要动它
• 别只重写部分构造函数，所有构造入口都要一致处理，否则行为不统一

Spring 中怎么让自定义异常被全局捕获

Spring 不会自动识别你的 BizException，得靠 @ExceptionHandler 或 @RestControllerAdvice 显式绑定。它和异常类本身无关，纯属框架配置。

常见错误现象：抛了 BizException，但返回的是默认 500 页面或空 JSON，没走你的异常处理器。

• 确保异常处理器类加了 @RestControllerAdvice 注解
• 方法上用 @ExceptionHandler(BizException.class) 明确指定类型
• 检查包扫描范围：该处理器类是否在 Spring Boot 主类同包或子包下？否则不会被加载
• 如果用了多个 Advice，注意 @Order 优先级，避免被更宽泛的 Exception.class 拦截器吃掉

复杂点在于：错误码要透传给前端，但又不能暴露内部细节。通常做法是在统一响应体里塞 code 字段，而不是直接把异常 message 当响应内容返回——message 是给人看的调试信息，code 才是机器可解析的契约。这点很容易被忽略，结果上线后前端靠字符串匹配做逻辑，一改提示就崩。

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