受检异常混淆业务分支与技术错误，迫使正常流程嵌入try-catch，破坏可读性、抽象性与函数式编程支持。

受检异常常被诟病，核心在于它把业务逻辑判断强行塞进异常流程，让代码读起来像在排查故障，而不是在表达业务规则。

混淆“错误”与“分支”

可预期的业务结果（如“库存不足”“手机号已注册”）本该用 if 判断 + 明确返回值表达，但一旦定义为受检异常，调用方就必须写 try-catch 或 throws。这导致：

• 正常流程被异常块切割，主干逻辑被淹没在 catch 块里
• 阅读代码时需反复跳转，无法一眼看出“什么条件下走哪条路”
• 同一个方法里混着技术异常（如文件读取失败）和业务拒绝（如参数校验不通过），语义模糊

污染接口契约

方法签名被迫暴露底层实现细节，破坏分层抽象：

• public Order createOrder(...) throws SQLException, IOException —— 调用方不该关心你是查数据库还是读配置文件
• 上层服务因底层变更被迫改签名，哪怕业务语义完全没变
• API 文档充斥技术异常类型，掩盖真实业务约束（比如“支付失败”实际只对应“余额不足”，却列了七八种 SQLException）

催生无效防御性代码

为满足编译要求，开发者常写出无实质处理的样板代码：

• 空 catch 块：catch (Exception e) { } —— 错误静默丢失
• 日志仅 printStackTrace()，未接入监控或告警体系
• 层层包装再抛：throws new RuntimeException(e) —— 编译检查形同虚设，还丢掉原始类型信息

干扰函数式与链式调用

Stream、Optional、CompletableFuture 等现代 API 的函数参数不支持 throws 声明：

• list.stream().map(s -> Files.readString(Path.of(s))) 直接编译失败
• 不得不额外封装工具方法，或改用 Optional.empty() 等替代方案，反而增加理解成本
• 业务逻辑被迫退回到传统 for 循环，放弃声明式表达优势