Java中try-with-resources通过异常抑制机制天然解决异常覆盖问题，确保业务异常为主异常，close异常自动addSuppressed附加其上；多资源按声明逆序关闭，首个close异常被抑制，其余可能覆盖，关键资源宜后声明。
Java 中 try-with-resources 通过异常抑制（Suppressed Exceptions）机制天然解决异常覆盖问题，核心是确保业务异常始终作为主异常抛出，而关闭阶段的异常不会把它“顶掉”。
异常覆盖的本质问题
在传统 try-finally 中，如果 try 块抛出 IOException，finally 里 close() 又抛出另一个 IOException，JVM 只向上抛出 close 的异常，原始业务异常被完全丢弃。调用方看到的错误信息与真实故障点脱节，排查困难。
try-with-resources 如何自动启用抑制
只要资源实现 AutoCloseable（如 FileInputStream、Connection、BufferedReader），声明在 try 括号中即可：
- 编译器自动生成资源关闭逻辑，按声明逆序执行 close()
- 若 try 块已抛异常，后续 close() 抛出的异常会自动调用 e.addSuppressed(closeEx)，附加到主异常上
- 无需手动捕获 close 异常，也不用写额外 try-catch
如何查看和处理被抑制的异常
主异常对象提供标准 API 访问被抑制项：
立即学习“Java免费学习笔记（深入）”；
- 调用 e.getSuppressed() 获取 Throwable 数组
- 遍历打印或记录日志，例如：System.err.println("被抑制: " + s.getMessage())
- 不显式检查时，JVM 默认只输出主异常；但堆栈中会标注 “Suppressed: …” 行，IDE 和日志框架通常能解析展示
多资源场景下的注意事项
多个资源共用一个 try-with-resources 时：
- 关闭顺序为声明的逆序（后声明的先关），影响异常抑制的先后关系
- 若多个 close 都失败，只有第一个 close 异常被抑制，其余可能被后续 close 异常覆盖——因此应尽量让关键资源后声明，使其 close 更早执行、更大概率成为被抑制者
- 所有资源必须满足 AutoCloseable，否则编译报错
