受检异常是java中强制编译期处理的异常机制，初衷提升健壮性，但实际常因模板化处理、圈复杂度增加、异常传递链和认知负荷上升而加剧代码复杂度；应通过场景区分、合并处理与工具辅助来约束其使用。
受检异常（Checked Exception）是 Java 的核心机制之一，它强制开发者在编译期处理可能发生的异常，初衷是提升健壮性。但实际工程中，它常常成为代码复杂度的重要推手——不是因为错误本身，而是因为它催生了大量模板式、防御性、嵌套式的处理逻辑。
受检异常放大圈复杂度
每多一个 try-catch 块，圈复杂度就 +1；每多一层 catch 分支（如同时捕获 SQLException、IOException、ClassNotFoundException），又额外增加独立路径。更隐蔽的是：为满足编译要求而添加的空 catch、日志后吞掉异常、或用 try-catch 包裹单行调用，表面“安全”，实则让控制流图膨胀，却未真正提升可靠性。
- 一个含 3 个受检异常调用的方法，若各自独立 try-catch，圈复杂度至少 +3；若合并处理且含 if 判定恢复策略，可能再 +2～4
- 案例中 OrderService.createOrder() 的静默 catch 就是典型：它没降低风险，反而掩盖了连接池耗尽的真实原因，还把 SQLException 和业务异常混在同一路径里
异常处理链导致认知负荷上升
受检异常常引发“异常传递链”：A 方法 throws XException → B 方法也 throws XException → C 方法 finally catch 并转成 RuntimeException。这种层层声明+转发，不增加功能价值，却显著抬高认知复杂度——阅读者需跨多个文件追踪异常流向，难以判断哪一层真正负责决策、哪一层只是机械透传。
- 当方法签名堆满 throws IOException, SQLException, TimeoutException，读者第一反应不是“这里可能出什么错”，而是“我得查文档才能知道怎么调用”
- 统一异常包装（如封装为 ServiceException）能缓解，但若包装逻辑分散在各 service 层，又会带来重复代码问题，进一步拉高重复率指标
可落地的简化策略
不必废除受检异常，关键在于约束其使用边界和表达意图：
- 区分场景：I/O、网络、数据库等外部依赖用受检异常合理；领域内业务规则校验（如“余额不足”）应抛运行时异常（RuntimeException 子类），由上层统一拦截返回友好提示
- 合并处理：对同一调用链中多个受检异常，优先用单一 try 块包裹，按异常类型做差异化响应，避免每个调用都配独立 try-catch
- 工具辅助：用 SonarQube 或 PMD 配置规则，对圈复杂度 >10 且含 ≥2 个 catch 块的方法自动告警；结合认知复杂度插件，识别深度嵌套的异常处理结构
本质上，受检异常不是复杂度的源头，而是复杂度的放大器。它把本该在设计阶段厘清的错误分类、恢复策略、责任归属，推迟到编码阶段靠语法强制补全，结果就是逻辑被异常处理稀释，主干路径越来越难看清。
