绝大多数情况下RuntimeException不该被显式catch，因其代表程序逻辑错误；仅在能明确恢复动作、统一异常处理或测试验证时才捕获，且应精准抛出自定义子类而非裸抛。
RuntimeException该不该catch
绝大多数情况下，RuntimeException不该被显式catch。它代表程序逻辑错误（比如空指针、数组越界、类型转换失败），不是外部可恢复的异常状态。强行捕获后仅printStackTrace()或吞掉异常，反而掩盖bug，让问题延迟暴露。
真正需要处理的，是能明确恢复动作的场景：
- 调用第三方SDK抛出的
IllegalArgumentException（属于RuntimeException），且你清楚参数校验规则，可以重试或降级 - 在Spring MVC中用
@ExceptionHandler统一捕获RuntimeException转成HTTP 400/500响应，但不推荐在业务方法里层层try-catch - 测试中故意触发
AssertJ断言失败（抛AssertionError）并验证异常行为
哪些RuntimeException适合主动抛出
主动抛RuntimeException子类，是表达“调用方违反契约”的最直接方式。关键不是“能不能抛”，而是“抛得是否精准”：
- 参数非法：用
IllegalArgumentException，比如public void setAge(int age) { if (age = 0"); } - 状态不合法：用
IllegalStateException，比如在对象未初始化完成时调用start() - 无法满足前置条件：用
UnsupportedOperationException，比如不可变集合的add()方法 - 避免用
RuntimeException裸抛——它没语义，排查时无法区分是NPE还是逻辑错
自定义RuntimeException要注意什么
自定义运行时异常本身很简单，但容易忽略两个实际影响：
立即学习“Java免费学习笔记（深入）”；
- 必须继承
RuntimeException（而非Exception），否则编译器会强制要求调用方处理，违背“非检查异常”设计初衷 - 构造函数建议至少提供
String message和Throwable cause两个重载，方便链式异常追踪 - 不要在异常类里加业务字段或复杂逻辑——异常对象应轻量，只承载错误上下文
- 命名需体现意图，如
InsufficientBalanceException比BusinessException更易理解
public class InsufficientBalanceException extends RuntimeException {
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}
和Checked Exception的边界在哪
判断一个异常该用RuntimeException还是检查异常（Exception子类），核心看“调用方能否合理预期并恢复”：
- 网络超时、数据库连接失败、文件不存在——这些外部依赖故障，调用方可能重试、切换备用源或提示用户，适合检查异常
- 传入
nullID查用户、对null对象调用方法、除零——这些是代码缺陷，修复靠改逻辑，不是靠catch，必须用RuntimeException - Spring的
DataAccessException体系是特例：它把JDBC的检查异常包装成运行时异常，因为数据访问失败通常无法在DAO层恢复，应交由上层决定是否重试或降级
最常被误用的是把“业务规则不满足”当成检查异常——比如“余额不足”应该抛InsufficientBalanceException（运行时），而不是InsufficientBalanceException extends Exception（检查）。否则每个支付调用都得写一堆try-catch，实际没人会处理，只是机械地往上抛。
