Java中如何选择继承Exception还是RuntimeException

Java中异常继承的选择本质是设计契约：当错误发生时，调用方是否必须且能够立即响应（如重试、降级、友好提示），就应继承Exception以强制处理；若错误源于代码缺陷、非法输入或不可控外部故障，且调用方无力合理恢复，则应继承RuntimeException让问题快速暴露、交由统一处理器兜底——选错父类不仅破坏API语义，还会催生大量无效try-catch、掩盖真实缺陷，真正关键的不是语法层面的继承关系，而是厘清“谁该在哪儿如何应对这个错误”。

继承 Exception 还是 RuntimeException？看调用方是否必须处理

Java 异常设计的核心判断标准不是“错得严不严重”，而是“这个错误发生时，调用方有没有能力或责任立刻恢复”。如果调用方**必须显式应对**（比如重试、降级、记录并通知用户），就该用 Exception；如果它大概率是代码缺陷或外部不可控故障（如空指针、网络超时、配置缺失），且调用方**无法合理处理**，就该用 RuntimeException。

• Exception 的子类是受检异常（checked exception），编译器强制要求 try-catch 或 throws，适合：文件不存在、SQL 语法错误、HTTP 返回 401 等明确可预判、有业务含义的失败
• RuntimeException 的子类是非受检异常（unchecked exception），编译器不干预，适合：NullPointerException、IllegalArgumentException、自定义的 InvalidConfigException（配置项为空）等逻辑校验失败
• 强行把本该是 RuntimeException 的异常声明为 Exception，会导致大量无意义的 try { ... } catch (Exception e) { throw new RuntimeException(e); }，掩盖真实问题

RuntimeException 子类该不该加 throws 声明？

绝大多数情况下——不需要。加了反而干扰阅读，还可能诱导调用方写空 catch。

• 只有当这个 RuntimeException 是**公开 API 的重要契约**（例如框架要求实现某个接口，其 Javadoc 明确说明“抛出 ValidationFailedException 表示参数校验失败”），才考虑在方法签名中写 throws ValidationFailedException
• 普通业务方法里自定义的 OrderAlreadyShippedException extends RuntimeException，直接 throw new OrderAlreadyShippedException() 即可，无需声明
• 加 throws 不影响运行时行为，但会让 IDE 和静态检查误以为这是“需要处理的异常”，增加维护成本

常见误用场景：什么时候不该继承 RuntimeException？

不是所有“运行时发生的错误”都适合继承 RuntimeException。关键看是否违背了“调用方无法/不应处理”的前提。

• 数据库连接失败（SQLException）——它是 Exception，因为上层可能要切换数据源或返回友好提示，属于可预期、需响应的外部依赖故障
• 第三方 HTTP 接口返回 503 ——建议封装为 ServiceUnavailableException extends Exception，而非 RuntimeException，否则熔断、重试逻辑容易被忽略
• 用户上传文件类型非法 ——应为 InvalidFileTypeException extends RuntimeException，因为这是输入校验失败，属于程序逻辑缺陷，不该由调用方“处理”，而应修正前端或增加校验

一个干净的自定义异常示例

下面是一个典型的、符合语义的 RuntimeException 子类写法，带必要构造函数和 serialVersionUID：

public class InsufficientBalanceException extends RuntimeException {
    private static final long serialVersionUID = 1L;

    public InsufficientBalanceException() {
        super("账户余额不足");
    }

    public InsufficientBalanceException(String message) {
        super(message);
    }

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

注意：没写 throws InsufficientBalanceException，构造函数覆盖全了常见调用方式，消息语义清晰且不含敏感信息。这种异常一旦抛出，就该让调用链终止，由全局异常处理器统一返回 400 和提示文案——这才是它该起的作用。

真正难的不是选哪个父类，而是想清楚：这个异常出现时，到底该由谁、在哪儿、以什么方式应对。父类只是信号灯，别让它变成挡路的路障。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。