前面的异常基础篇已经讲过，异常不是“程序报错时的一套语法糖”，而是一种明确责任边界的机制。到了这一篇，我们要把异常再往深处拆开看。因为只要项目开始进入分层、协作、日志治理和接口治理阶段，异常写法就不再只是个人习惯，而会直接影响系统的可维护性。
很多 Java 项目后期变得很难排障，问题往往不是异常太多，而是异常被写得没有层次。有人什么都 catch Exception，有人什么都往外 throws，有人为了“友好”把原始异常吞掉，最后接口层只剩一句“系统繁忙”。从业务视角看，用户看不懂；从研发视角看，开发也定位不了；从运维视角看，日志里还缺少关键上下文。这些问题本质上都和异常边界没设计好有关。
为什么异常机制在 Java 里格外重要？
Java 的一个鲜明特点，是它把异常处理提升到了语言结构层。也就是说，语言本身在提醒你：错误不是偶发现象，而是系统设计的一部分。你写一个方法，不只是要交代“正常情况下怎么返回”，还要交代“出错时由谁接手”。
这件事之所以重要，是因为服务端系统里常见的失败并不是单一类型：
- 用户输入不合法；
- 业务状态不满足要求；
- 数据库连接失败；
- 外部服务超时；
- 本地资源释放失败；
- 程序员写错了代码。
这些失败并不应该用同一种方式对待。业务错误和系统错误不一样，可恢复错误和不可恢复错误也不一样，应该提醒调用方的错误和应该在边界层统一兜底的错误同样不一样。Java 异常机制真正提供的，是一种把这些差异表达出来的能力。
checked 和 unchecked，到底在分什么？
很多人刚学异常时，会从继承关系去背：
- 继承
Exception且不是RuntimeException的，通常叫受检异常； - 继承
RuntimeException的，通常叫非受检异常。
这个记忆方法没错，但不够帮助你做工程判断。更有用的理解方式是从“调用方是否应该被强提醒”来区分。
checked exception 的核心含义
checked exception 更像是在告诉调用者：这个问题不是纯粹的编程失误，而是业务流程或外部环境中合理可能发生的失败，调用方最好显式面对它。
典型场景包括：
- 文件找不到；
- 网络资源不可达；
- 读取流失败；
- 反射调用时找不到目标成员。
这类异常的特点通常是，当前方法本身未必有能力完全恢复，但它不能假装这个失败不存在。于是 Java 通过编译器强制你做选择：捕获，或者继续上抛。
unchecked exception 的核心含义
unchecked exception 更强调：这是运行时问题、编程错误、前置条件不满足，或者不适合要求每一层都显式处理的问题。
最典型的包括：
NullPointerExceptionIllegalArgumentExceptionIllegalStateExceptionIndexOutOfBoundsException
这类异常之所以不要求强制处理，并不是因为它不严重，而是因为它往往不适合靠中间层逐层捕获。比如传入参数本来就错了，调用方如果没有修正输入，继续捕获再执行也没有意义。
真正要学会的是“恢复能力判断”
所以 checked / unchecked 的真正分界，不是“哪个高级”，而是：
- 这个失败是否值得强制调用方显式面对？
- 当前层有没有恢复能力？
- 如果继续向上抛，哪一层最适合把它变成稳定的外部结果？
一旦用这个思路去看，很多异常设计问题就不会停留在“背定义”层面。
throw 和 throws 分别代表什么责任？
throw 和 throws 经常一起出现，但它们表达的是两件不同的事。
throw：在当前层明确抛出问题
throw 表示当前代码决定中断当前流程，并把某个异常对象抛出去。这通常发生在两类场景里：
- 当前层主动发现了业务前置条件不满足；
- 当前层捕获了底层异常后，决定转换成更合适的语义异常。
例如，在服务层里发现订单状态不允许重复支付，你可以主动 throw new IllegalStateException(...) 或自定义业务异常。它表达的是：这不是自然崩掉，而是我们明确知道流程应该在这里终止。
throws：声明当前方法不负责在这里消化
throws 是方法签名层面的责任声明。它不是“我已经处理了”，而是“如果出现这类问题，我决定交给更外层处理”。
这背后反映的是分层责任。比如：
- 基础设施层可能把 I/O 异常继续抛给服务层；
- 服务层可能把业务异常继续抛给接口层；
- 接口层最终由全局异常处理器映射成 HTTP 响应。
所以 throws 不是甩锅，而是责任转移。前提是你要真的知道更外层能接住。
为什么异常链比“异常类型”还重要？
线上排障时，经常不是不知道异常发生了，而是不知道它最初是怎么发生的。这个问题通常出在异常链断了。
比如你在仓储层捕获了数据库异常，然后重新抛了一个业务异常，但没有把原始异常作为 cause 传进去，最后日志里就只剩一句“保存文章失败”。这句话对于用户可能足够友好，但对排障几乎没帮助。
更稳的做法通常是：
- 对外暴露时可以抽象语义；
- 对内记录时必须保留原始异常链；
- 包装异常时，把根因作为
cause传递下去； - 不要为了“代码整洁”丢失最关键的技术线索。
也就是说，异常包装可以做，但不能把根因抹掉。
try-catch 到底应该写在哪里？
很多项目的问题不在于没有 try-catch，而在于 try-catch 出现在了错误的层次。
不要在每一层都机械捕获
如果某一层没有恢复能力，只是捕获后打个日志再继续抛，那通常是在制造重复日志。这样不仅没有增加价值，还会让日志里同一个错误重复出现多次。
只在“能决定后续行为”的地方捕获
一个更成熟的原则是：只有当前层真的知道下一步该怎么办时，才值得捕获。
例如：
- 参数校验失败，可以直接转成清晰的业务异常；
- 连接第三方超时，可以做重试、降级或熔断判断；
- 读取文件失败，可以决定是否使用默认配置；
- 控制器层可以把异常转成统一响应结构。
如果你既不能恢复，也不能做出更有价值的决策，那么最好的选择往往是保留上下文后继续上抛。
try-with-resources 的价值不只是“少写 finally”
很多人知道 try-with-resources 是更简洁的写法，但它真正重要的地方在于：把资源生命周期纳入了语言结构。
在 I/O、JDBC、文件流、网络流这些场景里，最危险的问题常常不是主流程异常，而是资源没正确释放。资源泄漏通常不会第一时间爆炸，但它会在高并发或长时间运行后逐渐侵蚀系统稳定性。
try-with-resources 的价值在于：
- 资源释放路径更清晰；
- 主异常和关闭资源时的附加异常能更规范地组织；
- 代码意图更明确，不容易被后续维护者误改。
这说明异常处理和资源治理本来就是连在一起的，不应该被拆开看。
项目里怎样做异常分层，才不至于越写越乱？
一个更稳的分层方式，通常至少包括下面几层。
1. 基础设施层：保留技术细节，必要时做语义转换
这一层负责和数据库、缓存、文件、MQ、外部接口打交道。这里最重要的不是“全部吞掉技术异常”，而是：
- 识别底层技术异常；
- 在需要时转成更贴近上层语义的异常；
- 保留原始异常链和必要上下文。
例如，把底层的 SQL 异常包装成“数据访问失败”类异常，而不是把 JDBC 细节直接泄漏给服务层每个调用点。
2. 业务服务层：处理业务可决策错误
服务层最应该关注的是业务语义，比如：
- 状态不允许；
- 库存不足；
- 用户无权限；
- 幂等键冲突；
- 业务重复提交。
这类异常不应该被写成大量模糊的 RuntimeException("失败")，而应该让语义尽可能清晰。服务层不是为了捕获所有异常，而是为了对“业务为什么失败”给出稳定解释。
3. 接口边界层：统一对外暴露规则
控制器或全局异常处理器的职责不是“重新实现一遍业务逻辑”，而是：
- 把不同异常映射成一致的响应结构；
- 控制返回状态码、错误码和提示语；
- 区分用户可见信息和排障可见信息。
这一步非常关键。因为系统最终不是给开发自己看的，而是要对前端、调用方、运营后台提供稳定接口。
4. 日志与监控层：面向排障，而不是面向用户
用户提示应该克制，但日志必须完整。一个成熟的异常体系通常会把这两件事分开：
- 用户看到的是能理解的结果；
- 日志里保留请求标识、参数摘要、链路 ID、异常栈、依赖调用信息。
只有这样，异常分层才既有用户体验，也有工程可维护性。
业务异常、自定义异常，到底要不要建很多类？
这是很多团队都会纠结的问题。答案通常不是“越多越好”，也不是“一个万能异常类打天下”，而是要看系统复杂度。
更实用的经验是：
- 不要为每一个按钮点错一次都建一个新异常类；
- 也不要把所有业务失败都压成
BusinessException("失败")； - 优先围绕稳定业务边界定义少量高价值异常类型；
- 把错误码、业务语义、日志上下文结合起来看。
换句话说，异常类的数量不是目标，表达清晰才是目标。
最常见的异常设计误区
1. 到处 catch Exception
这会直接抹平错误边界。业务错误、参数错误、技术错误全被抓成一团，后续无论日志治理还是接口治理都会变得很难看。
2. 日志和异常都写了很多，但没有统一标准
最常见的后果是同一个异常在三层被重复打印三次，真正有价值的信息反而被冲掉。
3. 只想着“不要报错”，却不想“怎样定位”
短期看好像系统更稳定了，长期看会让所有问题都变成隐性问题。异常被压住，不等于问题被解决。
4. 包装异常时丢失原始 cause
这类问题线上一旦出现，往往只能靠猜。系统会留下“失败”的结论，却没有“为什么失败”的证据。
5. 把用户提示和系统日志混成一份
结果通常是用户看不懂、开发也不够用。对用户友好，不等于把异常栈直接打印到页面上；对开发友好，也不等于把所有实现细节原样透出给前端。
这一篇真正想建立的判断标准
学完异常机制深拆后，更重要的不是会不会背出 checked 和 unchecked，而是遇到一个失败场景时，你能不能按下面顺序思考：
1. 这个错误是业务错误、技术错误，还是编程错误？2. 当前层有没有恢复能力？3. 如果要向上抛，应该抛出什么语义？4. 原始异常链有没有被保留？5. 最终对外该如何稳定暴露，对内又怎样完整排障？
一旦这套判断顺序稳定下来，异常机制就不再是“写点 try-catch 的基本功”，而会变成系统分层能力的一部分。
总结
Java 异常机制真正厉害的地方，不在于它让代码多写了几行，而在于它逼着你面对失败边界。checked 和 unchecked 不是记忆题，throw 和 throws 也不是语法题，它们背后都是责任划分问题。只要你能把“错误分类、恢复能力、异常链保留、分层暴露”这四件事想清楚，异常系统就会从一堆令人厌烦的样板代码，变成项目可靠性的重要组成部分。