Java异常体系通过checked/unchecked分层强制区分外部风险与代码缺陷：IOException等checked异常须显式处理，NullPointerException等unchecked异常应通过防御编程预防；Error不可捕获，自定义异常依业务是否必须响应选择继承Exception或RuntimeException，并善用cause链式传递根因。
Java异常体系的设计初衷，是用编译器强制+语义分层，把“必须应对的外部风险”和“应该修复的代码缺陷”彻底分开。
为什么要把 Exception 分成 checked 和 unchecked 两类
这不是为了增加复杂度，而是为了在编译期就划清责任边界：
-
IOException、SQLException这类 checked 异常，代表程序逻辑没问题，但外部环境可能出问题（比如磁盘坏了、网络断了）。Java 要求你必须try-catch或throws，否则编译失败——这是在逼你正视依赖的不确定性。 -
NullPointerException、ArrayIndexOutOfBoundsException这类 unchecked 异常，继承自RuntimeException，编译器不管。因为它们几乎全是写错代码导致的，比如忘了判空、下标硬写list.get(100)。不强制捕获，是希望你用防御性编程（如Objects.requireNonNull()、集合 size 校验）提前拦住，而不是靠 try 块兜底。 - 混淆这两类，是新手最常踩的坑：对
NullPointerException写满catch块，却对FileNotFoundException甩手不管——结果是掩盖 bug，还让关键错误被忽略。
为什么 Error 类型几乎不该 catch
OutOfMemoryError、StackOverflowError 这些不是“异常”，是 JVM 已经撑不住的信号：
- 它们发生时，JVM 可能已处于不一致状态（比如堆内存全爆，连新异常对象都 new 不出来），此时任何
catch都不可靠。 - 试图
catch(Error)并继续运行，大概率引发更诡异的行为（如数据错乱、线程卡死），远不如让进程快速失败、触发监控告警来得安全。 - 真正该做的是：用
-Xmx调整堆大小、用jstack查栈溢出根源、用Arthas动态诊断——而不是写个catch块假装能处理。
自定义异常该继承 Exception 还是 RuntimeException
取决于你抛这个异常的意图：
立即学习“Java免费学习笔记（深入）”；
- 如果业务规则被破坏，且调用方**必须响应**（比如支付金额为负，下游系统要走退款流程），就继承
Exception。这样编译器会强制上层代码处理，避免漏掉关键分支。 - 如果只是参数明显非法（如传入
nullID 查询用户），属于调用方使用错误，就继承RuntimeException。这样既保留语义（说明是调用方问题），又不污染正常流程的 try-catch 结构。 - 别图省事全用
RuntimeException——那会让本该显式处理的业务异常，变成静默崩溃；也别滥用Exception——比如校验手机号格式这种纯输入检查，强制上层处理反而增加无谓负担。
最易被忽略的一点：Throwable 的构造方法里，cause 参数不是摆设。链式异常（new ServiceException("下单失败", e)）才能把原始根因（比如数据库连接超时）完整透出，否则日志里只剩一层包装，排查时只能靠猜。
