Java异常体系以Throwable为根，分Error（不可恢复）和Exception；后者含受检异常（编译强制处理，如IOException）与非受检异常（RuntimeException子类，如NPE）；自定义异常需据语义选继承父类，并注重可读性与链式追踪。
Java异常体系的核心在于分类明确、检查严格、处理可控。它不是简单的“出错就抛”，而是通过编译期与运行期的双重约束，强制开发者思考错误场景和恢复路径。
Throwable是所有异常的根类
Java中所有可抛出的异常或错误都继承自Throwable。它有两个直接子类：Error 和 Exception。
- Error 表示JVM无法恢复的严重问题，比如OutOfMemoryError、StackOverflowError。一般不捕获，也不应尝试处理。
- Exception 是程序可能遇到并应该主动应对的问题，进一步分为受检异常（Checked）和非受检异常（Unchecked）。
受检异常必须显式处理
以Exception为父类、但不继承自RuntimeException的异常，属于受检异常，例如IOException、SQLException。
编译器会强制要求：要么用try-catch捕获，要么在方法签名中用throws声明。
这种设计意图是提醒开发者——这类异常在正常流程中可能发生，且有恢复意义，比如文件不存在时提示用户重选路径。
非受检异常通常源于编程逻辑
RuntimeException及其子类（如NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException）属于非受检异常。
它们在编译期不强制处理，因为多数情况反映的是代码缺陷，应在测试阶段暴露并修复，而非靠运行时兜底。
不过，这不等于放任不管——关键业务逻辑中仍需有针对性地捕获，比如解析JSON时预判JSONException（若使用某些老版本库），或对用户输入做空值校验避免NPE。
自定义异常要讲清语义和用途
定义新异常时，优先继承Exception还是RuntimeException，取决于它是否需要强制调用方处理。
- 如果是业务规则导致的可预期失败（如“余额不足”、“订单已取消”），适合定义为受检异常，推动上游明确决策逻辑。
- 如果是内部状态不一致或非法参数等开发问题，更适合继承RuntimeException，保持调用简洁。
建议命名体现领域含义（如InsufficientBalanceException），并在构造函数中支持传入原始异常（cause），便于链式追踪。
基本上就这些。异常体系不是越复杂越好，关键是让错误可识别、可定位、可响应。
