Java中异常被“吞噬”是开发习惯导致的逻辑盲区，主因为空catch块、仅用e.printStackTrace()、丢弃受检异常cause链及忽略try-with-resources压制异常；须明确处理意图、用日志框架记录、保留异常链、检查压制异常。
Java中异常被“吞噬”不是语法问题，而是开发习惯导致的逻辑盲区——最常见的是空的 catch 块或仅调用 e.printStackTrace() 却未记录、未传播、未响应。
别写空的 catch 块
空 catch 是异常吞噬的头号元凶。它让错误静默失败，后续逻辑可能基于错误状态继续执行，引发更隐蔽的问题。
实操建议：
- 只要写了
catch，就必须明确处理意图：恢复、转换、记录、重抛，或至少打日志并标记为已知可忽略（需注释说明） - IDE 通常能警告空
catch，但别依赖它；Code Review 时重点扫一遍所有catch语句 - 若真确定该异常可忽略（如
InterruptedException在非中断敏感场景），也应显式调用Thread.currentThread().interrupt()并加注释
别只用 e.printStackTrace()
e.printStackTrace() 输出到 System.err，在容器环境、日志聚合系统中几乎不可见，且不带上下文（时间、线程名、业务ID），等于没记。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 统一使用 SLF4J / Log4j2 等日志框架，配合占位符：
logger.error("Failed to process order {}", orderId, e) - 确保异常对象作为最后一个参数传入，才能触发日志框架的异常堆栈自动捕获
- 避免拼接字符串记录异常信息（如
"Error: " + e.getMessage()），会丢失堆栈和 cause chain
检查受检异常是否被不当“吞掉”
Java 的受检异常（IOException、SQLException 等）强制你处理，但容易催生“假处理”：转成运行时异常却不留痕迹，或包装后丢弃原始异常链。
实操建议：
- 用
RuntimeException包装受检异常时，必须把原异常作为cause传入构造函数：throw new RuntimeException("DB query failed", e) - 不要用
new RuntimeException(e.getMessage())这种丢弃 cause 的写法，否则根因丢失 - 在 service 层或 API 边界，可将底层异常映射为业务异常（如
OrderNotFoundException），但要保留原始异常用于调试（可通过initCause()或构造函数注入）
注意 try-with-resources 中的异常压制
当 try 块和 close() 都抛异常时，try 中的异常是主异常，close() 异常会被压制（suppressed），默认不打印、不传播，极易被忽略。
实操建议：
- 在 catch 块中主动检查：
for (Throwable suppressed : e.getSuppressed()) { logger.warn("Suppressed during close", suppressed); } - 不要假设资源关闭一定成功；对关键资源（如文件写入、网络连接），考虑在
finally或单独逻辑中验证关闭结果 - 若关闭逻辑本身可能失败且影响业务（如事务回滚失败），不应依赖
try-with-resources自动关闭，而应显式控制生命周期
异常吞噬的本质，是把“程序不知道怎么处理”误当作“不需要处理”。真正难的不是语法，而是每次写 catch 前问自己一句：这个异常发生时，当前方法的调用者需要知道吗？下游系统能容忍它消失吗？日志里有没有足够信息让我三小时后还能定位？
