Java异常体系的根类是Throwable，它是Error和Exception的共同父类，定义了所有异常的通用属性和方法，但本身不可直接实例化或用于捕获兜底。
Java 异常体系的根是 Throwable，它不是用来直接使用的类，而是整个异常机制的顶层抽象。真正需要关注和区分的是它的两个直接子类：Error 和 Exception——它们代表两类性质完全不同的问题，设计意图、处理方式和实际影响都截然不同。
Throwable 是异常体系的统一入口，但绝不该被直接捕获
所有能被 throw 或 catch 的对象，必须是 Throwable 的实例。但它本身是抽象概念，就像“可抛出事物”这个分类标签。开发中写 catch (Throwable t) 看似“兜底最全”，实则危险：
- 会把
OutOfMemoryError、StackOverflowError这类 JVM 已濒临崩溃的信号也一并吞掉 - 掩盖系统级故障，让问题从“快速失败”变成“缓慢腐烂”
- 日志里出现大量被 catch 的
Error，往往是架构或资源管理存在隐患的明确信号
Error 表示 JVM 层面的严重故障，程序不应尝试恢复
Error 及其子类（如 OutOfMemoryError、StackOverflowError、NoClassDefFoundError）描述的是 JVM 自身无法维持正常运转的状态。这类问题的特点是：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 与业务代码逻辑无关，通常由资源耗尽、类加载失败或虚拟机内部错误引发
- 发生时，JVM 往往已失去执行任意 Java 代码的能力——比如 OOM 时连新建一个日志对象的内存都没有
- 即便语法上能
catch (Error e)，实际也无法做有效清理或恢复 - 正确做法是：监控告警 → 分析堆转储（jmap/jhat）→ 调整 JVM 参数或修复内存泄漏
Exception 才是开发者真正要应对的“异常”，分 checked 与 unchecked 两类
Exception 表示程序运行中可预见、可干预的非正常状态，是业务逻辑的一部分。它进一步分为：
立即学习“Java免费学习笔记（深入）”；
-
Checked 异常（受检异常）：如
IOException、SQLException。编译器强制要求处理——因为它们代表外部依赖（文件、网络、数据库）可能失败，且调用方通常有能力决定重试、降级或提示用户 -
Unchecked 异常（运行时异常）：即
RuntimeException及其子类，如NullPointerException、IllegalArgumentException、ArrayIndexOutOfBoundsException。编译器不强制处理，因为它们暴露的是代码缺陷（空指针、参数非法、越界），应通过逻辑校验提前拦截，而不是靠 catch 补救
自定义异常怎么选父类？关键看“谁该负责处理”
继承关系直接影响调用方是否必须显式处理：
- 如果异常发生后，**调用方有明确责任介入**（例如支付余额不足需走退款流程），就继承
Exception，让编译器强制约束 - 如果只是**内部校验失败或状态不一致**（例如配置项缺失、非法枚举值），继承
RuntimeException，避免污染方法签名，同时让问题在测试或上线初期快速暴露 - 永远不要继承
Error：这不是应用层该模拟的场景，也不符合语义
