java的try-with-resources在多重异常时保留主异常并抑制close异常，主异常反映业务根因，抑制异常体现善后失败；资源按声明逆序关闭，抑制异常通过getsuppressed()获取，需主动日志记录，避免finally中throw导致异常覆盖。
Java 的 try-with-resources 会自动处理多重异常：当 try 块抛出异常，且一个或多个资源的 close() 也抛出异常时，JVM 保留主异常（try 块中那个），并将 close 异常作为 suppressed exceptions 附加其上，而不是丢弃或覆盖。
主异常和抑制异常的分工要清楚
主异常代表业务失败的根本原因，比如数据库查询空指针、JSON 解析失败；抑制异常反映的是“善后失败”，比如连接归还超时、临时文件删除失败。排查问题必须先看主异常——它才是根因。抑制异常只是辅助信息，说明清理环节也不稳定，但修复主因后，很多抑制异常会自然消失。
多资源关闭时的抑制顺序有规律
资源按声明的逆序关闭：先声明的后关，后声明的先关。如果多个 close() 都抛异常，JVM 会把第一个 close 异常设为主异常（前提是 try 块没异常），后续 close 异常依次被 addSuppressed() 加入前一个异常的抑制列表。例如：
-
try (A a = new A(); B b = new B())→ 先调b.close()，再调a.close() - 若
b.close()抛IOException，a.close()也抛IOException，则后者被抑制并加到前者上 - 若 try 块已抛
NullPointerException，则两个 close 异常都会被抑制并加到该 NPE 上
查看和记录抑制异常不能靠默认打印
e.printStackTrace() 在标准控制台通常会显示 suppressed 异常（Java 7+），但在 IDE 控制台、Log4j 或 SLF4J 中往往被截断或完全不显示。必须主动处理：
- 调试时，在 IDE 中直接展开异常堆栈里的 “Suppressed: …” 节点
- 日志中显式调用
e.getSuppressed()并逐个打印，例如：
log.error("主异常: {}", e.getMessage());
for (Throwable s : e.getSuppressed()) {
log.warn("抑制异常: {}", s.getMessage());
} - 避免只记
e.getMessage()或只打 warn 级别日志——这样会彻底漏掉抑制项
手写 finally 时千万别 throw，否则就不是抑制而是覆盖
如果放弃 try-with-resources，改用传统 finally 关资源，常见错误是：
- 在
finally里直接调resource.close()而不包try-catch，一旦抛异常，原始异常就彻底丢失 - 在
catch中保存了异常，又在finally中throw new RuntimeException()—— JVM 不做任何附加，直接替换整个异常对象 - 正确做法：所有可能失败的清理操作（如
close()、delete()）都必须用独立try-catch包住，且catch里只记录日志或忽略，绝不可throw
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
