如何从受检异常重构代码至异常驱动模式

从受检异常转向异常驱动模式，这个转变听起来简单，但做起来可远不是把 throws IOException 换成 throw new RuntimeException(e) 就完事了。真正的关键在于，你得把异常当作梳理代码职责、明确错误语义、收紧调用契约的那条线索。说得直白点，异常应该是业务意图的表达载体，而不是技术故障的搬运工。

在DAO与Service的边界，做一次干净的异常转化

很多老项目里，SQLException、IOException 这些“技术味”十足的异常一路透传到 Controller，方法签名上堆满了 throws，业务逻辑被这些底层细节搅得一团乱。重构的第一步，就是划出一条清晰的“异常转化区”：

• DAO 层（或者 MyBatis 的 Mapper 实现）统一捕获底层的 IO/SQL 异常，然后转换成语义明确的运行时异常。比如 Spring 自带的 DataAccessException，或者你自己定义的 PersistenceException。
• Service 层的方法从此不再声明 throws SQLException 这类东西，专心处理业务规则。如果需要重试或降级，也应该基于运行时异常的类型去判断，而不是去检查原始异常类名这种技术细节。
• 一个容易踩的坑：在 Service 内部 catch 住异常，然后重新 throw 一个原始的受检异常。这种做法等于又把技术细节塞回业务层，必须避免。

用带业务含义的运行时异常，替代泛泛的RuntimeException

throw new RuntimeException(e) 虽然能通过编译，但代码的可维护性会大打折扣。更明智的做法是按失败场景来归类封装：

• 参数解析失败（比如 JSON 反序列化、日期格式错误）→ 可以使用 IllegalArgumentException 的子类，比如 InvalidRequestException。
• 外部服务不可用或超时 → 定义 ExternalServiceException，里面带上服务名、超时阈值等上下文信息。
• 状态不一致（比如订单已经支付了，却尝试去取消它）→ 用 IllegalStateException 的子类，比如 IllegalOrderStateException。
• 所有自定义异常，都必须提供一个接收 Throwable cause 的构造器，并且在日志里记录下原始异常类名和消息。这样才能保证出了问题可以追根溯源。

为Stream、CompletableFuture这些现代API，提供安全适配

受检异常在 lambda 表达式里就是个死结。没必要每个地方都写 try-catch，可以用更轻量的方式处理：

• 对于 Files.readAllLines()、BufferedReader.lines() 这类 IO 操作，直接使用 Ja va 8 内置的 UncheckedIOException 来包装，简单省事。
• 对于自定义的 IO 逻辑，可以提供一个工具方法，比如 IOFunctions.unchecked(Files::readAllLines)，它在内部完成 try-catch 和 UncheckedIOException 的构造。
• 最终工具方法返回的是 Function 这类没有异常声明的接口，让流式操作保持整洁。

配套全局处理器与可观测性，补全链路

把异常包装成运行时异常之后，问题定位的能力可不能跟着下降。必须同步落地一些支撑机制：

• 在 Spring Boot 中配置 @ControllerAdvice 全局异常处理器，统一响应格式（包含 status、code、message、traceId 等字段）。
• 对于关键异常类型，可以打上标记（比如用 @Loggable 注解），触发告警或自动创建工单。
• 日志中不仅要保留原始异常堆栈，还要注入业务上下文（比如运单号、用户ID、请求路径）。
• 配合 APM 工具（比如 SkyWalking）来追踪异常发生的位置和调用链路，做到“异常即指标”，让异常数据成为系统健康状况的晴雨表。