Java中受检异常需通过封装为业务异常、前置防护检查、分层捕获响应及模板方法统一处理，实现语义化、可观测、可恢复的异常管理。
受检异常（Checked Exception）在Java中是编译器强制要求处理的异常类型，如 IOException、SQLException、InterruptedException。它们代表与外部资源交互时可预期但不可控的失败场景。防御性设计不主张“绕过”受检异常，而是通过结构化、分层、语义明确的方式将其转化为可控、可观测、可恢复的业务信号。
用自定义业务异常封装受检异常
原始受检异常缺乏业务语义，直接抛出会污染调用链，也违背“异常应表达意图而非技术细节”的原则。
- 将
SQLException封装为OrderPersistenceException或InventoryLockFailedException，附带关键上下文（如订单ID、库存SKU） - DAO 层只抛出这类有业务含义的运行时异常（
RuntimeException子类），不再向上暴露原始 JDBC 异常 - 避免在 service 层写
catch(SQLException e) { throw new RuntimeException(e); }—— 这丢失了异常根源和恢复线索
在调用前做可预判的防护性检查
不是所有受检异常都只能靠 catch，很多可通过前置判断规避或降级。
- 文件操作前先用
Files.exists(path)和Files.isReadable(path)检查，再决定是否进入Files.readAllBytes()流程 - 数据库查询前校验分页参数：
if (page 1000) throw new ValidationException("非法分页参数")，防止SQLException因LIMIT -1或超大数据集触发 - 网络请求前检查本地配置（如 URL 是否为空、超时值是否合法），避免
MalformedURLException或IllegalArgumentException在连接阶段才暴露
按责任分层捕获与响应
受检异常的处理逻辑必须与代码职责对齐，不能全堆在 controller 或全甩给上层。
- 基础设施层（如 DAO、HTTP Client）：只负责转换——把原始受检异常转为带语义的运行时异常，并记录原始堆栈（用于问题回溯）
-
Service 层：专注补偿与重试策略。例如捕获
OrderPersistenceException后，启动本地事务回滚 + 发送补偿消息，而不是简单打印日志 -
Controller 层：面向用户做友好降级。比如捕获
PaymentTimeoutException（封装自InterruptedException）后，返回 “支付处理中，请稍后查看结果”，而非 500 错误页
用模板方法+回调规避重复 try-catch
频繁出现的受检异常处理逻辑（如文件读取、HTTP 调用）容易形成样板代码，可用模板方法统一收口。
- 定义通用模板：
<T> T executeWithResource(File file, Function<InputStream, T> processor) - 内部完成
try-with-resources、超时控制、异常转换，调用方只关注业务逻辑（processor） - 既保留了受检异常的强制约束力，又消除了散落在各处的冗余 try-catch 和资源释放错误
