异常吞没指捕获异常后不做有效处理，导致问题静默失败；应记录结构化日志、按业务语义重试/降级/抛自定义异常，或明确注释忽略原因，并借助静态检查与单元测试防范。
异常吞没（Exception Swallowing）是面试中高频考察的代码质量陷阱，指捕获异常后不做任何有效处理，比如只写个空的 catch 块或仅调用 e.printStackTrace() 而不记录、不响应、不传播。这会导致问题静默失败，调试困难，系统可靠性下降。
为什么空 catch 是危险的
看似“程序没崩”，实则埋下隐患：
- 掩盖真实故障原因：比如数据库连接失败被吞掉，上层业务却以为数据已保存成功
- 破坏调用链路：异常未向上抛出，导致事务未回滚、资源未释放、监控无告警
- 违反 fail-fast 原则：本该立即暴露的问题延迟到下游才暴露，定位成本指数级上升
常见吞没写法及修正方案
对照改写，立竿见影：
-
❌ 错误示范：
catch (IOException e) {}或catch (Exception e) { e.printStackTrace(); } -
✅ 正确做法：
- 记录结构化日志（含异常堆栈、上下文ID、关键参数），如用 SLF4J：
log.error("文件读取失败，路径={}", path, e); - 根据业务语义决定是否重试、降级或抛出自定义业务异常（如
throw new BusinessException("订单创建失败", "ORDER_CREATE_FAILED");） - 若确实无需业务响应（如异步清理任务失败），至少打 warn 日志并说明“可忽略”：
log.warn("清理临时文件失败，忽略：{}", tempFile, e);
- 记录结构化日志（含异常堆栈、上下文ID、关键参数），如用 SLF4J：
检查型异常的合理应对策略
IOException、SQLException 等受检异常容易被“迫于编译压力”而吞掉。正确姿势是：
- 不盲目
throws向上传递——要评估调用方是否有能力/职责处理它 - 在合适层级封装：DAO 层捕获
SQLException→ 转为DataAccessException（Spring 风格）→ Service 层决定是重试、补偿还是转为用户可见提示 - 用 try-with-resources 避免因资源未关闭引发的连锁异常，从源头减少异常发生概率
工具与习惯辅助识别
靠人眼审查容易遗漏，建议结合工程实践：
- 启用静态检查工具：SonarQube 规则
S1181（空 catch）、S1166（printStackTrace）；SpotBugs 的DE_MIGHT_IGNORE - 单元测试覆盖异常路径：用
Mockito.doThrow().when(...)模拟异常，验证日志是否打出、状态是否回滚、返回值是否符合预期 - 团队约定：所有
catch块必须含日志、抛异常、或明确注释“此处忽略，原因XXX”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
