Java异常体系设计初衷是什么？

Java异常体系的设计初衷并非制造复杂，而是通过编译器强制与语义分层，清晰划清“必须应对的外部不确定性”（如IO中断、网络故障）与“应当修复的代码缺陷”（如空指针、越界访问）之间的责任边界：checked异常强制处理以正视依赖风险，unchecked异常推动防御编程以根除bug，Error坚决不捕获以避免带病运行，自定义异常则依业务是否需强制响应来抉择继承路径，再辅以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

取决于你抛这个异常的意图：

• 如果业务规则被破坏，且调用方**必须响应**（比如支付金额为负，下游系统要走退款流程），就继承 Exception。这样编译器会强制上层代码处理，避免漏掉关键分支。
• 如果只是参数明显非法（如传入 null ID 查询用户），属于调用方使用错误，就继承 RuntimeException。这样既保留语义（说明是调用方问题），又不污染正常流程的 try-catch 结构。
• 别图省事全用 RuntimeException——那会让本该显式处理的业务异常，变成静默崩溃；也别滥用 Exception——比如校验手机号格式这种纯输入检查，强制上层处理反而增加无谓负担。

最易被忽略的一点：Throwable 的构造方法里，cause 参数不是摆设。链式异常（new ServiceException("下单失败", e)）才能把原始根因（比如数据库连接超时）完整透出，否则日志里只剩一层包装，排查时只能靠猜。

好了，本文到此结束，带大家了解了《Java异常体系设计初衷是什么？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！