受检异常的真正问题在于强制处理机制诱发过度捕获和伪处理。应区分“必须处理”与“必须在此处理”，在资源层捕获具体异常做最小响应，多数情况向上抛由高层统一决策；避免空catch、吞异常或无语义包装，可借鉴Spring的DataAccessException，解除强制但保留业务语义。
受检异常本身不是问题，但它的强制处理机制确实容易诱发过度捕获——关键不在“必须处理”，而在“怎么处理”。
强制处理不等于鼓励泛化捕获
Java 编译器要求你对 IOException、SQLException 等受检异常显式响应，要么 try-catch，要么 throws。这本意是把“外部可预期失败”暴露给调用方，促使其设计恢复策略（如重试、降级、提示用户）。但现实中，很多人直接写：
- catch (Exception e) { logger.error("出错了", e); } —— 吞掉所有异常，包括本该向上抛的受检异常和不该捕获的运行时异常
- catch (IOException e) { } —— 空 catch，既不补偿也不通知，调用方完全不知操作已失败
- 在工具方法里把 SQLException 包装成 RuntimeException 后“静默吞掉”，绕过编译检查，却丢掉了业务语义
真正的问题是混淆了“必须处理”和“必须在这里处理”
受检异常的强制性，是契约层面的提醒，不是执行层面的枷锁。合理做法是：
- 在靠近资源操作的位置捕获具体受检异常（如读文件时 catch FileNotFoundException），做最小必要响应（比如返回默认值或记录上下文）
- 多数情况下，让受检异常沿调用链向上抛，由更高层（如 Service 或 Controller）统一决策：重试？降级？转为用户友好的错误提示？
- 避免在 DAO 层就 catch SQLException 然后 return null；而应 throws，让业务层知道“数据库查不到”，而不是“查了个寂寞”
比捕获更危险的是“伪处理”
很多代码看似遵守了受检异常规则，实则埋雷：
- 只打日志不抛出，导致上层逻辑继续执行，状态错乱
- 捕获后返回错误码但未校验，下游照常使用无效数据
- 把受检异常转成 RuntimeException 却不加业务含义（如 new RuntimeException(e)），丢失原始类型和上下文
一个干净的替代思路：封装 + 显式语义
Spring 的 DataAccessException 就是范例：它把各种受检的 JDBC 异常统一转为非受检异常，但不是简单吞掉，而是保留根源、分类归因（ConcurrentUpdateException、DataIntegrityViolationException），让业务层能基于语义做精准响应。这种“解除强制但不丢语义”的方式，比硬扛 try-catch 更可持续。
