异常处理是Java开发中最基础也最容易写出问题的一个环节。不少代码里能看到这样的写法：catch块里空空如也，或者只有一行e.printStackTrace()，甚至直接注释一句"忽略即可"。这种捕获异常后不做有效处理的做法，通常被称为异常吞噬（exception swallowing）。它的问题在于，异常本身是程序出错时的报警信号，把信号吞掉并不代表错误不存在，只是让错误变得不可见了。等到故障发生时，排查的人面对的是一片"平静"的日志，根本无从下手。本文详细分析异常吞噬的常见形态、具体风险以及对应的正确处理方式。
异常吞噬的几种常见写法
第一种是最直接的空catch块，捕获之后什么都不做：
try {
parseConfig(file);
} catch (IOException e) {
// 什么都不做
}
第二种是只调用printStackTrace()，把堆栈打到标准错误流就算完事。这种写法在生产环境几乎等于没打日志，因为标准错误流往往不会进入日志采集系统，而且输出的内容没有时间戳、没有上下文，事后想从海量输出里找到它非常困难。
第三种更隐蔽一些，捕获后只打了一行没有信息量的日志，比如logger.info("出错了")。既没有异常对象，也没有说明是哪一步出错，这种日志在排查时基本没有价值。还有一种极端情况是在catch块里return null，调用方拿到null后可能引发空指针异常，把原本清晰的IO错误变成了一个莫名其妙的NullPointerException，错误信息反而更加模糊。
异常吞噬带来的具体风险
第一类风险是错误现场丢失。异常对象携带的堆栈信息只在异常发生那一刻是完整的，一旦被吞掉，出错时的线程、调用链、变量状态就再也找不回来了。比如一个配置解析失败被静默忽略，程序继续用默认值运行，表面上一切正常，实际上行为已经偏离预期。等下游业务出现数据异常再去追查时，根因早已无法还原。
第二类风险是系统进入不一致状态。异常往往意味着某个操作执行到一半失败了，比如转账流程中扣款成功但入账失败抛出了异常。如果这个异常被吞掉，事务没有回滚，数据库里就留下了不一致的数据。这类问题比程序崩溃更严重，因为崩溃至少能被及时发现，而数据不一致可能潜伏很久才暴露。
第三类风险与资源管理相关。如果异常发生在资源操作过程中，而catch块吞掉异常后没有清理资源，文件句柄、数据库连接就可能持续泄漏。累积到一定程度后，应用会报出Too many open files或连接池耗尽之类的错误，而这些错误的真正源头早在很久之前就被吞掉了。对比一下下面的两种写法就能看出差别：
// 有问题的写法：异常被吞，连接可能没有归还
public User queryUser(long id) {
Connection conn = null;
try {
conn = dataSource.getConnection();
return doQuery(conn, id);
} catch (SQLException e) {
return null; // 异常被吞，调用方无法感知失败
}
}
// 改进后的写法：记录日志并抛出运行时异常，资源由调用方或上层统一管理
public User queryUser(long id) {
try (Connection conn = dataSource.getConnection()) {
return doQuery(conn, id);
} catch (SQLException e) {
logger.error("查询用户失败, userId={}", id, e);
throw new DataAccessException("查询用户失败: " + id, e);
}
}
此外还有一个容易被忽视的风险：吞掉InterruptedException会破坏线程的取消机制。线程池调用shutdownNow时依赖中断信号让工作线程退出，如果任务代码把中断异常吞掉且没有恢复中断状态，线程就无法正常响应关闭，可能造成应用无法优雅停机。
正确的异常处理思路与最佳实践
处理异常的第一个原则是：要么处理，要么传递，不要假装处理。如果当前层有能力恢复错误，比如读取配置失败时回退到默认配置，那就应该在catch块里执行恢复逻辑，并记录一条warn级别的日志说明发生了回退。如果当前层没有能力处理，就应该把异常向上抛，让有能力处理的层来决策。抛出时可以包装成更符合业务语义的异常，但一定要把原始异常作为cause传进去，保住完整的因果链：
public Order loadOrder(long orderId) {
try {
return orderRepository.find(orderId);
} catch (SQLException e) {
// 包装异常时保留原始异常，不要丢失根因
throw new OrderServiceException("加载订单失败: " + orderId, e);
}
}
日志记录方面，务必把异常对象作为最后一个参数传给日志方法，并且只在最顶层记录一次，避免同一异常在多层重复打印。像下面这样的写法才能保留完整堆栈：
try {
transfer(fromAccount, toAccount, amount);
} catch (InsufficientBalanceException e) {
logger.error("转账失败, from={}, to={}, amount={}",
fromAccount, toAccount, amount, e);
throw e;
}
对于确实可以安全忽略的异常，比如关闭流时的IOException、反射访问不可达的字段，也不要留空块，至少写一条注释或debug日志说明忽略的理由。针对InterruptedException，标准做法是捕获后调用Thread.currentThread().interrupt()恢复中断状态，或者直接声明抛出。资源管理则优先使用try-with-resources语法，让编译器自动生成关闭逻辑，从根本上避免资源泄漏。最后，可以在代码审查中把空catch块当作坏味道重点检查，也可以借助静态分析工具如SpotBugs、SonarQube自动扫描，它们对异常吞噬都有专门的检测规则，能在编码阶段就拦住这类隐患。