Java异常体系以Throwable为根，分为Error和Exception；Exception再分Checked（编译期强制处理，如IOException）和Unchecked（运行时无需声明，如NullPointerException）两类，兼顾健壮性与灵活性。
Java的异常体系以Throwable为根，分为Error和Exception两大分支；其中Exception又进一步划分为编译期强制检查的Checked异常和运行时无需声明的Unchecked异常。这种分层设计兼顾了程序健壮性与开发灵活性。
Checked异常：编译器强制你面对的问题
Checked异常继承自Exception但不继承RuntimeException，典型如IOException、SQLException。它们代表程序**本可预期且应主动处理**的外部问题（比如文件不存在、网络超时）。
- 方法若可能抛出Checked异常，必须显式声明
throws，或在内部用try-catch捕获 - 调用方无法忽略——编译不通过，倒逼开发者思考“这个IO操作失败了怎么办？”
- 不是所有受检异常都值得保留：JDK 7后
AutoCloseable配合try-with-resources已大幅简化资源管理，部分场景可考虑封装或转为Unchecked
Unchecked异常：程序逻辑缺陷或不可控的运行时错误
Unchecked异常包括RuntimeException及其子类（如NullPointerException、ArrayIndexOutOfBoundsException）以及Error（如OutOfMemoryError）。它们在编译期不强制处理，因为：
-
RuntimeException多源于编程疏漏（空指针、越界），应靠测试和代码审查提前发现，而非靠try-catch掩盖 -
Error属于JVM级严重故障，应用通常无法恢复，捕获也无实际意义 - 过度捕获
RuntimeException反而模糊问题根源，比如对NullPointerException做空catch，等于隐藏bug
如何合理选择与设计自定义异常
新增异常类型时，核心判断依据是“调用方是否具备合理恢复能力”：
立即学习“Java免费学习笔记（深入）”；
- 若异常由外部环境导致（如第三方API限流、配置文件缺失），且业务逻辑能降级或重试，应继承
Exception，定义为Checked异常 - 若异常反映内部状态不一致（如参数校验失败、非法状态转移），应继承
RuntimeException，让问题快速暴露 - 避免滥用
Exception父类直接抛出；明确异常语义（如用InsufficientBalanceException而非泛化的BusinessException），便于上层精准处理
异常体系不是为了增加编码负担，而是用类型系统把“哪些错该被看见”“哪些错该被处理”显性化。用好Checked与Unchecked的边界，代码才既有防御力，又不失可读性。
