异常包装器模式：受检异常处理重构策略

异常处理虽然看似一个小话题，但几乎每个Java项目都踩过它的坑。尤其是受检异常（Checked Exception），当年Ja va语言设计者将其加入语法时，初衷是好的——强制开发者处理潜在的错误场景。然而在实际项目里，SQLException、IOException层层传递，方法签名上堆满了throws声明，代码读起来就像在啃一块硬骨头。

今天我们要聊的重构方向，并非彻底抛弃受检异常，而是采用一种更聪明的策略：将它们包装成带有业务语义的运行时异常。这样一来，编译检查不会阻止代码运行，同时异常本身也成为了业务表达的载体。

在 DAO 与 Service 边界做一次干净剥离

很多项目里都能看到这样的场景：Controller 层直接捕获 SQLException，甚至只在最上层打印堆栈就完事。技术细节和业务逻辑搅在一起，想拆都拆不开。

重构的关键，是划出一个清晰的“异常转化区”。

• DAO 层（包括 MyBatis Mapper 的实现类）统一拦截底层的 IO 异常、SQL 异常，然后转成语义明确的运行时异常——比如 Spring 自带的 DataAccessException，或者你自己定义的 PersistenceException。
• Service 层的方法签名里，再也看不到 throws SQLException 这样的声明。Service 只关心业务规则，它根据运行时异常的类型来决定要不要重试、降级，而不是依赖原始异常的类名。
• 特别提醒：不要在 Service 里 catch 住异常之后，又 throw 出原始的受检异常。那样等于把技术细节重新塞回业务逻辑，白忙一场。

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

throw new RuntimeException(e) 这种写法，虽然编译能过，但后续维护的人会想打人。因为没人知道这个异常到底代表了什么场景，只能靠看堆栈去猜测。

正确的做法是：按失败场景归类，封装成不同的异常子类。

• 参数解析失败（比如 JSON 反序列化出错、日期格式不对）→ 用 IllegalArgumentException 的子类，比如 InvalidRequestException。
• 外部服务不可用或超时 → 定义 ExternalServiceException，最好带上服务名、超时阈值等上下文信息。
• 业务状态不一致（例如订单已支付却尝试取消）→ 用 IllegalStateException 的子类，比如 IllegalOrderStateException。
• 所有自定义异常，必须提供 Throwable cause 构造器，并且在日志里把原始异常的类名和消息原样记录下来。

这样一来，异常本身就变成了业务信号。看异常名就知道问题出在哪个环节，比看堆栈猜快得多。

为 Stream、CompletableFuture 等现代 API 提供安全适配

受检异常在 Lambda 表达式里简直是噩梦——你没法在 Lambda 内部直接 throw 一个受检异常，除非你到处写 try-catch 然后转成运行时异常。但每个地方都这么干，代码冗余度会变得很高。

一个更轻量的做法是：借助工具方法做一次性包装。

• Files.readAllLines()、BufferedReader.lines() 这类标准 IO 方法，优先使用 Ja va 8 自带的 UncheckedIOException 来包装。
• 对于自定义的 IO 逻辑，可以写一个工具方法，比如 IOFunctions.unchecked(Files::readAllLines)，内部完成 try-catch 并构造 UncheckedIOException。
• 这个工具方法返回的是 Function> 这样的无异常声明接口，流式操作就能保持简洁。

这套适配方案，本质上就是“一次包装，处处使用”，既不用重复 try-catch，也不会让流式链被异常处理打断。

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

包装成运行时异常后，最大的隐忧是问题定位能力下降。因为运行时异常默认不会在编译期强制处理，万一漏掉，线上错误日志可能变得难以追踪。

所以配套的支撑机制必须跟上。

• 用 @ControllerAdvice 或 @ExceptionHandler 统一拦截 BusinessException 及其子类，返回结构化的错误响应，而不是直接抛 500。
• 所有异常在抛出之前，打点埋标：记录异常分类、触发路径、重试次数等维度，接入监控告警系统。
• 日志里必须保留完整的堆栈，让原始异常 cause 和当前层包装异常同时可见。这样才能支持逐层下钻排查，不会因为包装而丢失根源。

一句话总结：异常包装不是糊弄编译器，而是给错误起个有业务含义的名字，同时把各层职责理清。剩下的，靠全局处理和可观测性来兜底。