在 Java 项目里，异常吞噬指的是程序捕获了异常后既没有处理，也没有向上层抛出，导致调用方完全不知道发生过错误。这种方式会让接口看起来执行成功，实际业务却可能处于半失败状态。比如下单流程中，扣减库存成功但写订单表失败，如果异常被吞掉，用户会看到下单成功，但库存已经少了，订单数据却找不到。更麻烦的是，这类问题通常不会立刻暴露，往往要等到对账、盘点或用户投诉时才被发现，排查时又因为日志缺失而难以定位。
异常吞噬的典型场景
空 catch 块是最直接的异常吞噬形式。不少开发者在编译器的强制要求下，为了快速消除受检异常，会写一个空的 catch 代码块。虽然代码能通过编译，但异常发生后不会有任何反应。下面这段代码就是常见的问题写法，异常被完全忽略，方法继续返回，外部调用方根本不知道内部已经出错。
public void saveUser(User user) {
try {
userMapper.insert(user);
} catch (Exception e) {
// 这里什么都不做，异常被吞掉
}
}
另一种隐蔽形式是只打印堆栈但不重新抛出。有些项目会在 catch 里调用 e.printStackTrace() 或者用 System.out.println 打印异常，然后让方法正常返回。这种方式虽然留下了控制台输出，但在生产环境中控制台日志可能被重定向、被滚动覆盖，或者混在大量其他输出里，很难追查。更重要的是，调用方拿到的仍然是一个正常返回结果，后续逻辑会继续执行，可能把错误状态扩散到更多地方。
返回默认值同样危险。例如从数据库查询用户时发生异常，代码直接返回 null，调用方再对这个 null 做操作，往往会在很靠后的位置抛出 NullPointerException。此时堆栈信息已经和原始异常脱节，开发者需要在两个不相关的位置之间来回排查。类似的还有捕获后返回空集合、返回 0 或 false，这些都只是把问题推迟到更容易造成二次伤害的环节。
避免异常吞噬的核心原则
第一原则是捕获异常后必须有明确动作：要么在当前层完成有意义的恢复，要么把异常包装后重新抛出。如果当前方法确实无法处理某个异常，就不应该捕获它。比如数据访问层发生 SQLException，通常没有能力恢复数据库连接或修正 SQL 语句，这时应该让异常向上传播，由更上层的业务协调逻辑决定是重试、回滚还是返回失败提示。
第二原则是保留原始异常信息。Java 的异常链机制允许在创建新异常时把原始异常作为 cause 传入。例如在服务层捕获一个底层的 IOException，可以抛出一个业务异常，并把 IOException 放入 cause 中。这样做的好处是，上层既能识别业务错误类型，也能在日志中看到完整的根因堆栈。代码如下：
public Order createOrder(OrderRequest request) {
try {
return orderRepository.save(request);
} catch (IOException e) {
throw new OrderCreateException("创建订单失败，订单号=" + request.getOrderNo(), e);
}
}
第三原则是不要捕获 Throwable 或 Error。OutOfMemoryError、StackOverflowError 这类错误通常意味着 JVM 已经处于不稳定状态，应用层捕获它们并继续运行只会让系统行为更加不可预测。即使捕获了 Exception，也应该尽量避免捕获宽泛的 RuntimeException，除非是在线程池任务或消息消费的边界处做兜底，确保一个任务的失败不会导致整个线程终止。这种兜底也必须记录完整日志，而不是悄悄丢弃。
第四原则是用 try-with-resources 管理资源关闭。传统的 finally 块中如果资源关闭方法本身抛出异常，可能会覆盖 try 块里真正重要的业务异常，造成原始错误丢失。try-with-resources 会通过 addSuppressed 机制把关闭异常挂到主异常上，既不让关闭异常消失，也不会覆盖原始异常。这种方式对文件流、数据库连接、网络连接等场景都适用。
不同层级的最佳实践
在数据访问层，异常通常来自 JDBC、ORM 框架或连接池。这一层不应该把 SQLException 吞进肚子。可以采用统一的持久化异常转换，把底层异常包装成 DataAccessException，并在包装时保留原始异常。这样服务层只需要面对一致的数据访问异常类型，不必关心底层是 MyBatis 还是 JPA。如果使用了 Spring 框架，它已经提供了类似的异常转换机制，但仍然要检查自定义的 catch 块是否破坏了传播链。
在服务层，重点是区分可恢复异常和不可恢复异常。可恢复异常例如库存不足、余额不足，这类业务失败可以通过返回错误码或抛出业务异常让调用方进行分支处理。不可恢复异常例如网络超时、数据库连接断开，则应向上抛出或由全局异常处理器统一转换为用户可理解的提示。服务层捕获异常时，最好补充当前操作的上下文信息，比如用户 ID、订单号、请求参数摘要，这些信息对后续排查非常有价值。
在异步任务和消息消费端，异常吞噬更常见，因为任务通常没有直接的同步调用方，开发者容易觉得抛出去也没人接。但正确做法是：在 Runnable 或 Consumer 的边界捕获 Exception，记录完整日志，同时可以触发告警、写入重试队列或把失败原因保存到任务状态表。静默失败在异步链路中影响最大，因为没有任何用户会立即反馈错误。
异常日志与代码审查建议
记录异常日志时，至少应包含异常类型、异常消息、堆栈信息以及必要的业务上下文。推荐使用 SLF4J 的参数化日志方式，避免字符串拼接带来的性能损耗，也能保留完整堆栈。例如 log.error("处理订单失败, orderNo={}", orderNo, e); 这种写法，SLF4J 会自动识别最后一个参数为异常对象并输出堆栈。不要只记录 e.getMessage()，很多异常的消息为空或过于简短，只看消息很难定位问题。
代码审查时，可以重点关注所有 catch 块。如果 catch 块中只有注释而没有可执行语句，直接判定为异常吞噬。如果 catch 块只有 printStackTrace 或简单日志但没有重新抛出，也需要评估调用方是否还能正确感知失败。还可以借助静态代码分析工具，例如 SonarQube 的规则会发现空 catch 和忽略异常的情况。把这类规则纳入持续集成检查，能有效减少异常吞噬进入主干代码的机会。
最后要建立团队层面的异常处理约定。例如：业务层抛出的自定义异常统一继承 RuntimeException，并由全局异常处理器转换为标准响应；受检异常在明确无法恢复时使用包装方式转换为运行时异常；永远不要为了通过编译而添加空 catch。这些约定要落实到代码模板和评审清单中，而不是只停留在文档里。异常处理不是让代码不报错，而是让错误在正确的层次、以正确的方式暴露出来。