java try-with-resources中关闭异常会被压制而非丢弃，需通过getsuppressed()显式检查并记录；close应静默处理预期失败，仅对严重问题抛runtimeexception；必要时改用手动finally管理。
Java 处理 try-with-resources 关闭资源时抛出的异常，核心不是“阻止它发生”，而是**正确理解压制（suppression）机制，并主动检查、记录或响应被压制的异常**。默认情况下，close() 抛出的异常不会覆盖业务异常，但也不会自动显示——必须手动干预才能看到。
关闭异常会被自动压制，而不是丢弃
当 try 块已抛出异常（如 IOException 或 NullPointerException），而某个资源的 close() 方法又抛出另一个异常时，JVM 会把 close 异常作为“被抑制异常”附加到主异常上，调用的是 addSuppressed() 方法。
- 主异常（try 块中抛出的）始终是最终抛出的那个
- close 异常不会消失，而是存进 e.getSuppressed() 返回的 Throwable[] 数组里
- 如果 try 块没抛异常，而多个 close 都失败，则第一个关闭失败的异常作为主异常抛出，其余被压制
必须显式检查 getSuppressed() 才能看到关闭异常
仅靠 e.printStackTrace() 或 log.error("", e) 在部分环境（如某些 IDE 控制台、Log4j 默认配置）中可能不显示 suppressed 区块，容易误判问题根源。
- 在 catch 块中，先判断 e.getSuppressed().length > 0
- 遍历数组，对每个压制异常提取关键信息：例如 s.getMessage() 或 s.getClass().getSimpleName()
- 日志中建议分开记录：主异常用 error 级别，压制异常用 warn 级别并标注 “Suppressed”
让 close 方法更健壮，减少干扰性异常
close 的职责是“尽最大努力清理”，不应因资源已关闭、连接已断开等常见终态而抛出检查型异常。
- 在 close 实现中捕获并静默处理已关闭/无效状态引发的异常（如 SocketException: socket closed）
- 只对真正危险的情况抛 RuntimeException（如 flush 缓冲区失败且数据可能丢失）
- 可参考 Closeables.closeQuietly() 的设计思路：吞掉预期中的静默失败
必要时放弃 try-with-resources，改用手动 finally 管理
当需要控制关闭顺序、单独重试某资源、或 close 行为高度定制时，传统方式反而更清晰可靠。
- 每个 close 调用都包裹独立的 try-catch，绝不在其中 throw 新异常
- 若需保留原始异常，按标准模式：先保存主异常，close 失败时调用 primary.addSuppressed(e)
- 避免在 finally 中直接写 resource.close() 不加 try-catch——这是覆盖原始异常的高发场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
