RuntimeException 是 unchecked 异常，编译器不强制处理；其子类及 Error 的子类均属 unchecked，而继承 Exception（非 RuntimeException）的为 checked 异常；是否受检取决于继承关系而非名称或发生时机。
RuntimeException 是 unchecked 异常，编译器不强制处理
Java 把 Exception 分成两大类：checked（受检）和 unchecked（非受检）。RuntimeException 及其子类属于 unchecked，意味着你调用一个可能抛出 NullPointerException 或 ArrayIndexOutOfBoundsException 的方法时，编译器不会报错，也不要求你写 try-catch 或声明 throws。
而普通 Exception（比如 IOException、SQLException）是 checked 的——不处理就编译失败。
- 这是语言设计上的区分：checked 异常代表「预期外但可恢复的外部问题」（如文件不存在、网络超时），应由调用方显式决策；
- unchecked 异常代表「程序逻辑错误」（空指针、越界、类型转换失败），本不该发生，修复代码比捕获更合理；
- 别为了过编译而随便加
catch (Exception e) { }，这会掩盖真正的 bug。
继承关系决定行为，不是名字决定的
是否为 unchecked，只看它是不是 RuntimeException 或 Error 的子类。哪怕你自定义一个叫 MyBusinessException 的异常，只要它继承 Exception（而非 RuntimeException），它就是 checked 异常。
反过来说，如果你继承 RuntimeException 写了个 ValidationFailedException，它就自动变成 unchecked，无需 throws 声明。
立即学习“Java免费学习笔记（深入）”；
- 常见误区：以为“运行时异常”只发生在运行期——其实所有异常都发生在运行期，关键在编译期是否检查；
-
Exception是父类，RuntimeException是它的直接子类； - 不要因为某个异常类名里没 “Runtime” 就误判它是否受检，查源码或 IDE 的继承树最可靠。
该捕获哪个？看能否有意义地恢复
面对 RuntimeException，多数情况不该捕获——比如 NullPointerException 暴露的是你忘了判空，补上 if (obj != null) 才是正解，而不是包一层 try-catch 吞掉它。
但也有例外：框架层（如 Spring MVC）会统一捕获 RuntimeException 转成 HTTP 500；或者你在解析用户输入时，用 NumberFormatException 判定输入格式非法，这时捕获反而更清晰。
- 能预判并主动规避的，优先改逻辑（如判空、校验集合 size）；
- 属于用户输入或外部数据导致的「可预期的失败」，且有明确 fallback 行为（如返回默认值、提示友好错误），可以捕获特定
RuntimeException； - 永远避免
catch (Exception e)或catch (RuntimeException e)空处理，除非你真要记录日志后重新抛出。
自定义异常时，选 Exception 还是 RuntimeException？
取决于你希望调用方「必须处理」还是「自行决定是否处理」。例如：
public class InsufficientBalanceException extends Exception { ... } // 调用方必须 try 或 throws
public class InvalidTokenException extends RuntimeException { ... } // 调用方可选择忽略
微服务中常见做法：BusinessException 继承 RuntimeException，配合全局异常处理器统一返回 JSON 错误；而涉及 IO、资源访问的异常（如 ConfigLoadException）若希望启动阶段就失败，可设为 checked。
- 如果异常表示「调用方应该知道并响应」，用 checked；
- 如果异常表示「调用方很难提前预防，出了就该修代码」，用 unchecked；
- Spring 的
DataAccessException体系全继承RuntimeException，就是为了不让 DAO 层代码被throws污染——这个设计取舍很典型。
最易被忽略的一点：同一个异常类，在不同模块语义可能不同。比如 IllegalArgumentException 在工具类里是 unchecked 逻辑错，在 API 入口层却可能被当作用户参数错误来捕获并返回 400 ——关键不在它是什么类，而在你用它表达什么意图。
