受检异常本身不是问题，关键在于正确使用：过度封装、硬塞私有方法、用runtimeexception包装、空catch等做法导致代码僵化、语义丢失、根因难查；健康做法是暴露意图、提供策略入口、统一封装并保留业务语义。

受检异常本身不是问题，问题出在怎么用它。过度封装受检异常，本质上是把“必须处理”的编译约束，错当成“必须隐藏”或“必须包装”的设计义务，结果让代码越来越僵、越来越难维护——这正是代码腐烂的典型诱因之一。

把受检异常硬塞进私有方法，等于堵死调用方的应对路径

比如一个读取配置文件的方法，声明抛出 IOException（典型的受检异常），本意是提醒调用方：文件可能不存在、权限不够、磁盘已满。但如果开发者把它封装进一个私有工具类里，又不暴露重试、降级、兜底等策略入口，调用方就只剩两个选择：要么复制粘贴整段逻辑，要么绕过工具直接写IO代码。

• 不提供可配置的重试次数和间隔，调用方无法适配网络不稳定场景
• 不开放 fallback 值设置，业务无法在配置缺失时返回默认行为
• 不支持自定义异常转换，导致上层无法区分“文件未找到”和“编码错误”

用 RuntimeException 包装所有受检异常，等于废掉编译检查的价值

有些团队为图省事，把 SQLException 或 HttpClientErrorException 全部 catch 后再 throw new RuntimeException(e)，美其名曰“统一异常类型”。这看似简化了代码，实则抹掉了关键语义：

Multi-Brain Protocol

一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。

下载

• 编译器不再提醒你处理数据库连接失败这类可恢复问题
• 调用方无法基于异常类型做差异化响应（如重试 vs 立即报错）
• 日志中只剩泛化的 RuntimeException，丢失原始上下文和堆栈根源

层层 try-catch + 空 catch + e.printStackTrace()，是腐烂加速器

这不是封装，是掩盖。尤其当多个服务调用嵌套时，每个层级都写一个空 catch 或只打一行 printStackTrace，结果就是：

• 异常被吞掉，前端只看到“系统错误”，后端查不到根因
• 相同异常在不同层重复捕获，修复一处，其他层照样崩
• 业务逻辑被大量样板代码淹没，新人根本看不出主干流程在哪

真正健康的封装，是暴露意图，隐藏实现

面对受检异常，好的做法不是藏起来，而是帮调用方更轻松地表达意图：

• 提供带默认策略的高层 API：readConfig().orElse(defaultConfig)
• 允许传入 RecoveryPolicy：readConfig().onFailure(retry(3).withBackoff())
• 用自定义受检异常承载业务语义：ConfigLoadException extends Exception，附带 error code 和 source location
• 在 Service 层统一封装，Controller 层只关注“成功/失败”，不碰 IOException 或 SQLException

不复杂但容易忽略：受检异常的设计初衷，是让开发者在编译期就思考“这个失败我打算怎么应对”。一旦跳过这步思考，靠 runtime 崩溃来提醒，那代码腐烂就已经开始了。