避免吞掉异常信息的关键是捕获后不丢弃、不掩盖、不静默：保留原始异常链，明确处理意图，正确使用日志；禁用空catch；日志须传异常对象而非字符串；包装异常必须显式传cause；finally中禁止抛异常；try-with-resources需处理suppressed异常。
避免吞掉异常信息，关键不是“不捕获”，而是“捕获后不丢弃、不掩盖、不静默”。重点在于保留原始异常链、明确处理意图、用对日志方式。
别写空的 catch 块
空 catch 是最典型的异常吞噬行为——代码继续执行，但错误状态被忽略，后续逻辑可能基于错误数据运行，问题越埋越深。
- 只要写了 catch，就必须有明确动作：记录日志、转换为业务异常、重抛、或显式标记为可忽略（并加注释说明理由）
- IDE 警告不可依赖，Code Review 时要专门扫一遍所有 catch 块
- 真确定可忽略（比如非中断敏感场景下的 InterruptedException），也要调用 Thread.currentThread().interrupt() 并注释原因
日志必须传入异常对象，别拼字符串
e.printStackTrace() 只输出到 System.err，在容器环境里基本看不到；而 logger.error("msg" + e) 会丢失堆栈和 cause 链，等于没记。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 统一用 SLF4J 或 Log4j2，且异常对象必须作为最后一个参数传入：logger.error("Failed to process order {}", orderId, e)
- 禁止手动拼接 getMessage() 或 toString() 写进日志，那只是文本，不是可解析的异常上下文
- 敏感字段（如手机号、token）要在日志前脱敏，避免泄露
构造包装异常时，必须显式传 cause
用 new RuntimeException("xxx") 包装底层异常，或者只调用 super(message) 再 initCause(e)，都会断裂异常链。工具链（Sentry、ELK、Spring 异常处理器）全靠 getCause() 向下追溯根因。
- 自定义业务异常类必须重载全部四个构造方法，并在每个方法中调用 super(message, cause) 或 super(cause)
- 禁止写 new RuntimeException(e.getMessage()) —— 完全丢弃原始异常
- 在全局异常处理器（@ControllerAdvice）中，直接返回原始异常实例或其子类，不要 new 一个新 RuntimeException 替换它
小心 finally 和 try-with-resources 的压制异常
try 块已抛异常，finally 又抛异常，JVM 会丢弃 try 中的异常，只留下 finally 的——这是规范行为，极易误导排查。
- finally 块中禁止抛出任何异常；资源关闭失败应捕获并 warn 日志，不 rethrow
- 用 try-with-resources 替代手动 close，它能自动把 close 失败的异常设为 suppressed，可通过 e.getSuppressed() 检查
- 在 catch 块中记得遍历并记录 suppressed 异常，否则它们会被静默忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
