受检异常是Java中强制处理的异常，用于暴露、分类、隔离和恢复外部不确定性；应设计业务恢复路径，封装为语义化异常，合理声明throws，并用策略模式实现可配置的异常响应。

受检异常（Checked Exception）是 Java 中强制要求处理的异常类型，它的存在本身就是为了推动开发者在编译期就面对潜在风险——这恰恰是防御性编码的天然入口。用好受检异常，不是为了“应付编译器”，而是把系统脆弱点提前暴露、分类、隔离和恢复。

明确区分“必须处理”和“不该发生”

受检异常代表的是程序运行中**可能合理发生、调用方有责任应对**的外部不确定性，比如文件不存在、网络超时、数据库连接失败。它们不是 bug，而是现实环境的一部分。

• ✅ 正确做法：为每个受检异常设计对应的业务恢复路径，例如重试、降级、记录告警、返回友好提示
• ❌ 错误做法：用 catch (Exception e) { e.printStackTrace(); } 吞掉异常，或简单抛出 new RuntimeException(e) 掩盖问题
• 关键判断：如果某个受检异常在当前上下文中“理论上不可能出现”，说明接口契约或前置校验缺失，应补上输入验证或状态检查，而非靠 catch 挡住

封装底层受检异常，暴露语义化业务异常

直接把 IOException 或 SQLException 向上抛，会让调用方陷入技术细节，也破坏了分层职责。防御性做法是做一层语义转换。

• 定义清晰的业务异常类，如 OrderCreationFailureException、PaymentTimeoutException
• 在 DAO 或 Client 层捕获原始受检异常，结合上下文补充原因（如“支付网关响应超时，订单号：ORD-20260611001”），再包装抛出
• 这样上层 Service 只需关注“订单创建失败了怎么办”，无需知道是 socket 断开还是 JSON 解析失败

用 throws 声明代替静默吞没

当方法内部无法独立完成恢复，且该异常对调用方有意义时，应主动声明 throws，而不是自己消化。

• 例如读取配置文件的方法：public Config loadConfig() throws ConfigLoadException
• 这迫使调用方思考：“如果配置加载失败，我是否能继续？要不要 fallback？要不要告警？”
• 比起隐藏风险，让异常“浮出水面”才是真正的防御——它激活了整个调用链的风险意识和协作机制

配合策略模式做可配置的异常响应

同一类受检异常，在不同场景下应有不同应对逻辑。硬编码多个 if-else 容易失控，建议引入策略。

• 定义策略接口：interface ExceptionHandlingStrategy { void handle(IOException e, Context ctx); }
• 实现多种策略：重试三次、切换备用源、返回缓存数据、直接失败并通知运维
• 运行时根据环境（测试/预发/生产）、业务重要性（支付 vs 日志上报）动态选择策略
• 这种结构让防御行为可观察、可配置、可演进，而不是写死在某段 try-catch 里