空 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）有文档说明为何忽略。常见误判场景：
立即学习“Java免费学习笔记（深入）”；
-
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 的异常体系，本就是为强制你思考这个分类而设计的。
