异常抑制机制的核心作用是防止资源关闭异常覆盖主业务异常，即当try块已抛异常且close()再抛异常时，后者被addSuppressed()添加为主异常的抑制异常，通过e.getSuppressed()获取，确保上下文完整。
异常抑制机制的核心作用，是防止资源关闭时的异常覆盖主业务异常。它不是隐藏错误，而是把次要异常“挂”在主异常上，保留完整上下文。
什么情况下会触发异常抑制
必须同时满足两个条件：
- try 块已抛出一个异常（主异常），导致 try-with-resources 非正常退出
- 某个资源的 close() 方法在自动调用时也抛出了异常
此时，close 抛出的异常不会取代主异常，而是被 JVM 自动调用 addSuppressed() 添加到主异常中。如果多个资源 close 失败，后关闭的资源异常会先被添加，再被更早关闭资源的异常覆盖式追加（按逆序关闭顺序）。
被抑制的异常存哪儿、怎么取
所有被抑制的异常都保存在主异常对象内部，通过标准 API 获取：
-
e.getSuppressed() 返回
Throwable[]，长度为实际被抑制的异常个数 - 每个元素都是完整异常实例，包含自己的消息、类型和栈轨迹
- 注意：默认 printStackTrace() 在 IDE 控制台或某些日志框架里可能不显示被抑制部分，需显式遍历打印
close() 方法能抛什么异常
AutoCloseable 接口定义 close() throws Exception，意味着：
- 可以合法抛出受检异常（如 IOException），但调用方必须处理
- 运行时异常（如 RuntimeException）可直接抛，无需声明
- 不能声明抛出比 Exception 更宽泛的 Throwable（如 Error），否则编译失败
实践中，标准库资源（如 FileInputStream、Connection）的 close() 多数只抛 IOException，属于受检异常；自定义实现时应保持语义一致。
常见误判与调试建议
开发者容易忽略被抑制异常，导致问题定位偏差：
- 只看 e.getMessage() 或默认堆栈，误以为“关闭没出错”
- 在 catch 块中未检查 getSuppressed()，漏掉关键线索（比如文件读取失败 + 关闭时磁盘满）
- 手动 new 异常后调用 addSuppressed()，因无真实栈帧，调试价值低
建议在关键异常处理路径中固定加入抑制异常的日志输出逻辑，尤其在 I/O、数据库、网络等易发生双重异常的场景。
