JVM将close()异常作为被抑制异常自动addSuppressed()到主异常上，而非丢弃或覆盖；必须显式调用getSuppressed()获取Throwable[]数组并遍历记录，否则日志或IDE中易漏看。
当 try-with-resources 的 try 块中已抛出一个异常（比如 IOException），而某个资源的 close() 方法在自动调用时又抛出另一个异常（比如 SocketException），JVM 不会丢弃后者，也不会让它覆盖前者。而是将 close() 抛出的异常作为被抑制异常（suppressed exception），通过 addSuppressed() 方法附加到主异常对象上。
这个过程是 JVM 自动完成的，无需手动调用 addSuppressed()，但前提是：
- 资源实现了
AutoCloseable接口； -
close()方法确实抛出了异常； - try 块中已有异常正在传播（即尚未被 catch 捕获并终止传播）。
关键机制如下：
- 主异常（try 块内首个未被捕获的异常）始终是最终向外抛出的那个；
- 后续所有
close()异常都会被调用primaryException.addSuppressed(suppressedException)加入其内部 suppressed 列表； - 这些被抑制异常可通过
e.getSuppressed()获取，返回Throwable[]数组； - 若 try 块本身没抛异常，而多个
close()都失败，则第一个close()异常成为主异常，其余仍被压制。
常见误区提醒：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
e.printStackTrace()在某些 IDE 或日志框架（如 Log4j 默认配置）中默认不打印 suppressed 区块，容易误判为“关闭异常消失了”； -
catch块中若只写log.error("", e)，很可能漏掉被抑制的异常信息； - 不应在
finally中裸写resource.close()—— 这种写法无法触发 suppression 机制，反而可能覆盖原始异常。
如何确保看到被抑制异常：
- 在
catch块中检查if (e.getSuppressed().length > 0)； - 遍历
e.getSuppressed()，对每个异常提取类名和消息； - 日志中分开记录：主异常用
error级别，压制异常用warn级别并标注 “Suppressed”。
本质上，这不是“隐式 catch”，而是 JVM 对异常传播路径的智能编排 —— 它保留了全部上下文，只是需要你主动伸手去拿。
