addSuppressed()必须在主异常抛出前调用，仅对未抛出的Throwable有效；典型用于try-with-resources或手动资源释放的finally块中，压制关闭异常，且需确保主异常非null、不为自身。
Java中addSuppressed()该在什么时机调用
必须在主异常被抛出前调用，且只能对已创建但尚未抛出的Throwable实例操作。一旦throw e执行，再调用addSuppressed()无效——它不会报错，但被压制的异常根本不会出现在堆栈里。
典型场景是try-with-resources自动关闭失败时，JVM底层会自动调用addSuppressed()把关闭异常加到主异常上；手动管理资源时，得自己在finally块里判断并调用。
- 主异常对象（如
e）必须是新构造的，或从捕获点重新抛出前的引用 - 被压制异常不能为
null，否则抛NullPointerException - 不能压制自身（
e.addSuppressed(e)）——会抛IllegalArgumentException -
addSuppressed()是Throwable方法，所有异常类型都可用，不限于Exception
手动资源释放时怎么安全调用addSuppressed()
别在catch里直接throw主异常后补调用，那是徒劳。正确做法是在finally中先尝试释放，捕获关闭异常，再决定是否压制。
示例：手动关闭InputStream时发生IO异常，而主逻辑已抛出ParseException：
立即学习“Java免费学习笔记（深入）”；
ParseException mainEx = null;
try {
parseData(input);
} catch (ParseException e) {
mainEx = e;
} finally {
try {
if (input != null) input.close();
} catch (IOException closeEx) {
if (mainEx != null) {
mainEx.addSuppressed(closeEx);
}
// 不在此处throw！留给外层统一处理
}
}
if (mainEx != null) throw mainEx;
- 务必检查
mainEx != null，避免对null调用addSuppressed() - 不要在
catch里throw后再进finally——此时异常已离开当前栈帧 - 压制的异常不会改变主异常的类型或
getMessage()，只影响getSuppressed()返回值
addSuppressed()和initCause()的区别别搞混
两者完全不是一回事：initCause()设置的是“根本原因（cause）”，一个异常只能有一个；addSuppressed()添加的是“伴随异常（suppressed）”，可以多个，且语义是“本想做某事，但因主异常发生而被抑制了”。
比如解析JSON失败（主异常），同时临时文件删不掉（被压制）——删除失败不是导致解析失败的原因，只是清理阶段的副作用。
-
getCause()返回null或单个Throwable；getSuppressed()返回Throwable[]，可能为空数组 - 序列化时，
cause会被保留；suppressed在Java 7+默认也序列化，但某些旧版RPC框架可能忽略 - 日志框架（如Log4j2）默认只打印
cause链，要显示suppressed需显式配置或调用Throwable.printStackTrace()
被压制异常的可见性与调试陷阱
IDE调试时，断点停在throw mainEx那行，mainEx.getSuppressed().length可能为0——因为压制操作发生在之前，但IDE未必实时刷新内部状态。真正要看，得在抛出后捕获它再查。
更隐蔽的问题：如果主异常是自定义类且重写了printStackTrace()但没调用super.printStackTrace()，所有被压制异常都会消失不见。
- JDK自带异常（
RuntimeException等）默认打印会包含Suppressed:段落，但前提是没被上层吞掉 - Spring等框架拦截异常时，若只取
e.getMessage()或e.toString()，suppressed信息彻底丢失 - 单元测试里验证压制异常，要用
assertThat(e.getSuppressed(), arrayWithSize(1))，而不是依赖字符串匹配
压制异常不是“附加日志”，它是结构化的一部分，漏掉检查或误用打印方式，等于白加。
