Java异常体系以Throwable为根，分为Error（不捕获）和Exception；Exception又分RuntimeException（非受检，如NullPointerException）和受检异常（如IOException，必须声明或捕获）。
Java异常体系是 Throwable 为根的树状结构，所有异常必须继承它；不继承 Throwable 的类哪怕名字带“Exception”，也不是合法异常。
Throwable 的两个直接子类：Error 和 Exception
Error 表示 JVM 无法恢复的严重问题（如 OutOfMemoryError、StackOverflowError），程序一般不应捕获或处理；Exception 才是开发者真正要面对的异常主体。
关键区别在于：Error 不强制要求声明或捕获，而 Exception 分为两类：
-
RuntimeException及其子类：运行时异常，编译器不检查（un-checked），比如NullPointerException、ArrayIndexOutOfBoundsException - 其他
Exception子类（如IOException、SQLException）：受检异常（checked），方法签名必须用throws声明，或在调用处用try-catch处理
常见的 RuntimeException 子类及典型触发场景
这些异常多数源于编程疏漏，不抛出具体堆栈也常能从代码逻辑中推断：
立即学习“Java免费学习笔记（深入）”；
-
NullPointerException：调用null引用的实例方法、访问字段、数组长度等 -
ArrayIndexOutOfBoundsException：下标或 <code>>= array.length -
ClassCastException：非法强转，如(String) new Object() -
IllegalArgumentException：传入方法的参数明显不合逻辑（如Thread.sleep(-1)） -
ConcurrentModificationException：遍历集合时被其他线程或同一线程的迭代器外操作修改了结构
注意：RuntimeException 虽不强制处理，但生产环境应尽量避免——它们反映的是可预防的代码缺陷，而非外部不确定性。
受检异常（Checked Exception）为什么必须显式处理？
设计意图是让开发者「正视不可控外部因素」：文件可能不存在、网络可能超时、数据库连接可能中断。JVM 强制你直面这些可能性，而不是静默忽略。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
常见受检异常包括：
-
IOException：读写文件、网络流、序列化失败 -
SQLException：SQL 执行错误、连接失效、事务冲突 -
ClassNotFoundException：反射时类名拼错或类未加载 -
InterruptedException：线程被中断且当前方法声明抛出该异常（如Thread.sleep()）
容易踩的坑：
- 用空
catch吞掉受检异常（如catch (IOException e) {}），等于放弃错误反馈 - 在 lambda 表达式中抛出受检异常却没用
try-catch包裹，导致编译失败（函数式接口方法通常不声明throws） - 把
IOException直接包装成RuntimeException后向上抛，掩盖了原始异常类型和上下文
自定义异常该怎么继承？选 RuntimeException 还是 Exception？
取决于你希望调用方是否「被迫处理」：
- 如果异常代表业务规则失败（如余额不足、状态非法），且调用方本就应该做决策（拒绝请求 / 降级 / 提示用户），推荐继承
RuntimeException—— 避免污染接口契约 - 如果异常代表必须响应的外部故障（如支付网关暂时不可用），且上层有统一重试/熔断机制，可继承
Exception，强制调用链显式传递
无论哪种，都建议提供带 String message 和 Throwable cause 的构造函数，并在必要时重写 getMessage() 以增强可读性。
一个最小可用的自定义运行时异常示例：
public class InsufficientBalanceException extends RuntimeException {
public InsufficientBalanceException(String message) {
super(message);
}
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}
真正难的不是分清继承关系，而是判断某个异常该不该被“捕获并吞掉”、该不该“转换语义后重抛”、或者该不该“记录后继续传播”。这需要结合上下文，而不是查类图就能决定的。
