Java异常处理误区：如何避免吞掉异常

空 catch 块是危险的，它隐藏异常导致问题不可见、诊断线索全失，破坏中断语义、事务回滚，并制造虚假安全感；应记录带上下文的日志，精准分类异常，仅极少数明确无副作用且有文档说明时才可忽略。

Java里用空的 catch 块吞异常，等于在代码里埋雷——它不会让程序立刻崩，但会让问题彻底失去可见性，排查时只能靠猜。

为什么 catch (Exception e) {} 是最危险的写法

这种写法表面“兜住了错误”，实际切断了所有诊断线索：堆栈没打、日志没留、上游无法感知失败。更糟的是，它常出现在多线程、IO、RPC等关键路径上，导致超时、数据不一致、重试风暴等问题迟迟无法定位。

• 编译器不会报错，IDE 甚至可能提示“已处理异常”，造成虚假安全感
• 如果 e 是 InterruptedException，还可能破坏线程中断语义，导致线程无法被正常终止
• 在 Spring 等框架中，吞掉异常会让事务回滚失效（@Transactional 默认只对 unchecked 异常回滚）

该记录日志时，必须明确记录什么

不是所有异常都要打印完整堆栈，但至少得留下可追溯的上下文。重点不是“有没有 log”，而是“能不能凭这条日志找到现场”。

• 避免只写 log.error("出错了") —— 缺少异常类型、关键变量值、业务ID
• 推荐格式：log.error("订单支付回调失败，orderNo={}, cause={}", orderNo, e.getMessage(), e)
• 敏感信息（如银行卡号、token）要脱敏，但不能因此把整个异常对象丢弃
• 对可预期的业务异常（如库存不足），优先用自定义异常 + 业务码，而非泛化捕获 Exception

什么时候可以忽略异常？只有极少数情况

真能“忽略”的异常极少，且必须满足两个条件：1）完全确定它无副作用；2）有文档说明为何忽略。常见误判场景：

• Thread.sleep(100) 的 InterruptedException：不能空 catch，应恢复中断状态 Thread.currentThread().interrupt()
• close() 方法抛出的 IOException：JDK 7+ 推荐用 try-with-resources，否则需单独捕获并记录，不能因“关流不影响主逻辑”就吞掉
• 某些工具类的解析失败（如 Integer.parseInt）：应提前校验字符串格式，而不是靠 catch 来做流程控制

try {
    result = riskyOperation();
} catch (SpecificException e) {
    // 明确知道这是可恢复的瞬时失败
    log.warn("调用降级，使用本地缓存", e);
    result = getFromCache();
} catch (FatalException e) {
    // 不做任何恢复，直接向上抛，由全局异常处理器统一处理
    throw e;
}

真正难的不是“要不要 catch”，而是分清哪些异常属于系统故障、哪些是业务规则、哪些是编程错误。吞异常的本质，是对异常分类的懒惰——而 Java 的异常体系，本就是为强制你思考这个分类而设计的。