防范异常静默吞没的关键是确保 catch 必须记录日志、重抛或明确兜底，禁用空 catch 和 e.printstacktrace()；finally 禁止 return 或 throw；统一在分层入口处理异常；并用工具强制拦截静默路径。
防范 try-catch 块内控制结构导致异常被静默吞没，关键在于不让异常“消失”在逻辑分支、返回语句或空处理中。真正危险的不是异常发生，而是它发生后没人知道、没人记录、没人传递。
避免在 catch 中无动作或仅打印堆栈
空 catch 或仅调用 e.printStackTrace() 是最常见也最危险的静默源头。控制台输出在生产环境不可见，且不带业务上下文，等于把错误藏进黑箱。
- 所有
catch必须至少做一件事：记录带异常对象的日志（log.error("处理订单失败", e)）、包装重抛（throw new BusinessException("支付超时", e)），或明确兜底并注释原因 - 禁止写
catch (Exception e) { }或catch (Exception e) { e.printStackTrace(); } - 日志必须包含可定位信息：如订单 ID、用户 ID、操作时间戳，并通过 MDC 注入 traceId
警惕 finally 中的 return 和新异常
finally 不是“收尾保险”，而是异常覆盖高发区。一旦它执行 return 或抛出新异常，原始异常就彻底丢失。
- 绝对禁止在 finally 中写
return或throw—— 它会中断异常传播链，让上游完全感知不到错误 - 若资源关闭可能失败（如
close()抛 IOException），应捕获该异常并用primaryException.addSuppressed(closeException)关联，而非放任其覆盖主异常 - 优先使用
try-with-resources替代手写 finally，JVM 自动处理抑制异常，保障根因可见
不靠 try-catch 分散拦截，而靠分层统一收口
在每个循环项、每个回调、每个第三方调用点都加 try-catch，反而放大静默风险。应把异常处理收敛到可控入口。
- 批量操作中，不要为每一项单独套 try-catch（如
for (item : list) { try { process(item); } catch (...) {...} }），这会导致失败项无声跳过，数据不一致却无告警 - 改用全局未捕获异常处理器（
Thread.setDefaultUncaughtExceptionHandler）兜底线程级异常 - Web 层统一用
@RestControllerAdvice处理所有异常：业务异常转标准响应，系统异常记全栈日志，受检异常映射 HTTP 状态码 - 对 CompletableFuture、Future 等异步调用，强制补
.exceptionally(e -> { log.error(...); return null; })，不依赖其默认静默行为
用工具卡住静默路径
单靠人工审查难以杜绝吞异常，需机制化拦截。
- 在 SonarQube 或 SpotBugs 中启用规则：RSPEC-1166（空 catch）、RSPEC-2583（日志缺失异常参数）、RSPEC-1149（finally 含 return/throw）
- IDE 配置 Live Template，输入
tc自动生成带 SLF4J 日志和 re-throw 的标准 catch 块 - CI 流水线中加入静态检查门禁，违反规范的代码禁止合入
