addsuppressed() 是将次要异常附着到主异常以防止丢失的机制，而非异常处理器；真正处理需显式调用 getsuppressed() 遍历并记录日志或打印堆栈。

Java 的 addSuppressed() 不是“处理”异常的处理器，而是把次要异常**附着到主异常上**，确保它不被丢弃。真正“处理”被压制异常，靠的是后续显式调用 getSuppressed() 并做日志、告警或诊断——否则它们就像隐身了一样，控制台里根本看不到。

什么时候该用 addSuppressed()

只在以下情况手动调用：

• 主逻辑已失败（比如解析 JSON 报错、数据库写入失败），你捕获了这个异常（称为主异常）
• 紧接着在清理阶段（如关闭流、删除临时文件、释放锁）又发生了另一个独立异常
• 你希望保留这个清理异常的上下文，又不想让它覆盖主异常

典型位置是 finally 块中：先尝试清理，捕获其异常，再检查主异常是否存在，存在则调用 mainEx.addSuppressed(cleanupEx)。

怎么安全调用 addSuppressed()

必须避开几个常见坑：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 主异常对象不能为 null，否则抛 NullPointerException
• 不能把同一个异常对象重复添加，也不能加自己（e.addSuppressed(e)），否则抛 IllegalArgumentException
• 必须在主异常 throw 之前调用；一旦抛出，再调用就无效（不报错，但没效果）
• 被压制异常本身也不能为空引用

示例片段：

ParseException mainEx = null;
try { parse(input); }
catch (ParseException e) { mainEx = e; }
finally {
  try { input.close(); }
  catch (IOException closeEx) {
    if (mainEx != null) mainEx.addSuppressed(closeEx);
  }
}
if (mainEx != null) throw mainEx;

怎么真正“处理”被压制的异常

addSuppressed() 只负责存，不负责显。要让被压制异常发挥作用，必须主动拉出来：

• 调用 e.getSuppressed() 获取 Throwable[] 数组（长度可能为 0）
• 遍历数组，对每个被抑制异常调用 printStackTrace() 或记录到日志中
• 在自定义日志框架（如 SLF4J + Logback）中，需显式循环打印，否则默认日志里不显示 suppressed 部分
• IDE（如 IntelliJ）调试时会自动折叠显示 “Suppressed: …”，点开即可查看，适合快速定位

别把被抑制异常当主因——它只是“善后失败”，排查优先级永远低于主异常。

和 try-with-resources 的关系

try-with-resources 是 addSuppressed() 的自动应用场：只要 try 块抛异常，且任一资源 close() 也抛异常，JVM 就自动把后者压制到前者上。但要注意：

• 多个资源关闭都失败时，JVM 只自动压制第一个 close() 异常，其余可能被忽略
• 若你想确保所有关闭异常都不丢，就得手动管理：逐个 close() 并捕获、全部 addSuppressed()
• getSuppressed().length == 0 不代表关闭成功——可能只是 try 块没抛异常，此时 close() 异常会直接作为主异常抛出

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南