空 catch 块会静默吞噬异常，导致事务未回滚、资源未释放、监控失效等隐蔽问题；正确做法是记录日志、重抛业务异常、执行补偿或明确注释忽略原因。
空 catch 块会导致异常被静默吞噬
Java 中写 try { ... } catch (Exception e) { } 这种空 catch 块，等于主动丢弃异常信息。程序看似“没崩”，但实际可能已处于不一致状态：数据库事务没回滚、文件句柄没释放、缓存没更新、下游调用超时未感知——所有这些都不会报错，只会悄悄出错。
常见误用场景和对应风险
这类写法常出现在以下位置，每个都有明确后果：
-
资源关闭逻辑中：比如在
finally里调用close()抛出IOException，却用空catch吞掉——连接泄漏、文件锁残留、内存占用持续上升 - 日志上报失败兜底：想“保证主流程不因日志失败中断”，结果监控告警全失效，线上问题失去可观测性
-
第三方 SDK 调用包装：把
SomeSdk.doAction()包进空try-catch，SDK 内部的重试机制、熔断标记、上下文透传全部失效
正确做法不是“不处理”，而是“有意识地处理”
捕获异常后至少要满足以下一项，才算合理处理：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 记录可定位的日志：
log.error("Failed to process order {}", orderId, e); - 转换为业务语义更清晰的异常并重新抛出：
throw new OrderValidationException("Invalid payment method", e); - 执行确定的补偿动作（如回滚、清理、降级）：
cache.evict(key); - 明确声明该异常可忽略（需注释说明原因）：
// 忽略文件不存在，由后续流程创建
try {
Files.delete(Paths.get(tempPath));
} catch (NoSuchFileException ignored) {
// 文件本就不存在，无需处理
} catch (IOException e) {
log.warn("Failed to delete temp file {}, continuing anyway", tempPath, e);
}
IDE 和静态检查能帮你发现这类问题
IntelliJ 默认会标红空 catch 块；SonarQube 规则 S1181（"Exception handlers should not be empty"）也会告警。但更关键的是团队约定：任何 catch 块必须含日志、重抛、补偿三者之一，否则 PR 不通过。
立即学习“Java免费学习笔记（深入）”；
最隐蔽的风险不是程序崩溃，而是它“太稳定”——稳定到你根本不知道哪条路径已经失效了。
