应继承Exception当调用方必须显式处理（如重试、降级），继承RuntimeException当属代码缺陷或不可控故障且无法合理处理；前者为受检异常，后者为非受检异常。
继承 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：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
立即学习“Java免费学习笔记（深入）”；
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 和提示文案——这才是它该起的作用。
真正难的不是选哪个父类，而是想清楚：这个异常出现时，到底该由谁、在哪儿、以什么方式应对。父类只是信号灯，别让它变成挡路的路障。
