Java异常体系以Throwable为唯一根类，JVM强制所有异常继承它；Error表示不可恢复的JVM底层错误，禁止捕获；Exception分受检与非受检两类，自定义异常应据处理意图选择继承关系，并遵循命名与安全规范。
Java 的异常体系不是靠“分类讲解”就能理清的，关键在于理解 Throwable 是唯一根、所有异常都必须直接或间接继承它，且它的两个子类 Error 和 Exception 在语义和使用场景上被严格区分——这不是约定，是 JVM 强制执行的契约。
Throwable 为什么必须是所有异常的父类
JVM 在抛出异常时只认 Throwable 及其子类；任何非 Throwable 类型的对象调用 throw 都会编译失败。它的设计核心是封装三要素：异常消息（message）、堆栈快照（stackTrace）、可选的 cause（Throwable 类型的嵌套异常）。构造时若未显式传入 cause，initCause() 仍可后期绑定，但仅限一次。
-
Throwable默认构造函数会自动填充当前线程堆栈，不可跳过 - 子类重写
fillInStackTrace()可拦截堆栈收集（如性能敏感的自定义异常） -
getStackTrace()返回的是副本，修改它不影响实际异常行为
Error 和 Exception 的分界不是“严重程度”，而是“能否被合理捕获”
Error 表示 JVM 无法恢复的底层问题（如 OutOfMemoryError、StackOverflowError），JVM 规范明确禁止应用代码捕获它们——不是语法不允许，而是捕获后几乎无法做有意义的处理，反而掩盖真实故障点。而 Exception 分为两类：
- 受检异常（
Checked Exception）：编译器强制要求声明或捕获，适用于可预期、可恢复的外部故障（如IOException、SQLException） - 非受检异常（
RuntimeException及其子类）：编译器不检查，代表程序逻辑错误（如NullPointerException、ArrayIndexOutOfBoundsException），应通过修复代码而非 try-catch 来解决
混淆这两类会导致异常处理逻辑膨胀且失效：比如对 NullPointerException 做空 catch，只会让 bug 沉淀得更深。
立即学习“Java免费学习笔记（深入）”；
自定义异常该继承 Exception 还是 RuntimeException
取决于你希望调用方“必须处理”还是“允许忽略”。如果异常代表业务规则被违反（如余额不足、参数非法），且调用方有明确的兜底策略（如提示用户、降级返回），就该继承 RuntimeException；如果异常对应外部系统不可用（如支付网关超时），且调用方需主动重试或切换通道，则应继承 Exception 并在方法签名中声明。
- 继承
Exception时，别忘了提供带cause的构造函数，方便包装底层异常 - 所有自定义异常类名应以
Exception结尾（如InsufficientBalanceException），这是 JVM 生态的隐式规范 - 避免在
toString()或getMessage()中拼接敏感信息（如数据库密码），日志输出时可能泄露
try-with-resources 和 finally 中的异常压制（suppression）机制
当 try 块抛出异常，且 finally 或 try-with-resources 的 close() 也抛异常时，JVM 会将后者作为 suppressed exception 附加到主异常上，而不是覆盖它。可通过 getSuppressed() 获取数组，但要注意：
- 只有 JDK 7+ 的
Throwable才支持 suppression，老版本中close()异常会直接丢失 - suppressed 异常不会触发外层 catch，除非显式遍历
getSuppressed() - 自定义异常若重写了
addSuppressed()，必须调用super.addSuppressed()，否则压制链断裂
真正难的从来不是记住类图，而是每次写 throw 前想清楚：这个异常，是该让调用方看见、处理、还是根本就该让它崩掉。
