try-with-resources 中关闭异常被抑制而不打断主异常链，需用 getsuppressed() 获取；仅当 try 块无异常时关闭异常才直接抛出；资源须实现 autocloseable，编译器不强制处理其 close() 的 checked exception。
Java 中 try-with-resources 在关闭资源时如果抛出 checked exception，它不会打断当前的异常传播链，而是被抑制（suppressed），除非 try 块本身没抛异常——此时它会作为主异常抛出。
资源关闭异常会被抑制，不覆盖主异常
当 try 块中已抛出一个异常（比如 IOException），而资源在自动关闭时又抛出另一个 checked exception（如 SQLException），后者会被添加为“被抑制异常”（suppressed exception），原异常仍为主异常。调用 getCause() 拿不到它，需用 getSuppressed() 获取。
- try 块抛异常 → 关闭异常被抑制，可通过
exception.getSuppressed()查看 - try 块没抛异常 → 关闭异常直接抛出（哪怕它是 checked）
- 多个资源关闭都失败 → 所有关闭异常都会被抑制，按声明顺序逆序加入
try-with-resources 要求资源实现 AutoCloseable
只有实现了 AutoCloseable 接口的类才能用于 try-with-resources。它的 close() 方法声明抛出 Exception，所以任何 checked exception 都能被合法抛出。编译器不会强制你捕获关闭时的异常，因为语义上它属于“清理阶段”，不是业务逻辑主路径。
-
Closeable是AutoCloseable的子接口，close()声明抛IOException - 自定义资源只需实现
AutoCloseable，close()中可自由 throw 任意 Exception - 即使
close()抛出 checked exception，也不需要在 try-with-resources 外显式 catch 它
手动处理关闭异常的场景很少，但可以做
绝大多数情况下，让异常被抑制即可；但若需对关闭失败做特殊响应（如记录、重试、告警），可把资源声明移出 try-with-resources，改用手动 close 并包裹 try-catch。
- 例如：数据库连接池中某些连接 close 失败需单独上报，不适合混在业务异常里
- 不推荐在
close()里吞掉异常（即空 catch），这会掩盖问题 - 若必须捕获关闭异常，建议记录日志并 re-throw 或包装成 RuntimeException
常见误区：以为必须捕获 close() 的 checked exception
很多人看到 close() 声明 throws Exception 就下意识加 catch，但在 try-with-resources 中这是多余的。JVM 会自动处理关闭逻辑和异常抑制，无需干预。
- 写法错误：
try (FileInputStream fis = new FileInputStream("a.txt")) { ... } catch (IOException e) { ... }—— 这里的 catch 只捕获 try 块异常，不捕获 close 异常 - 真正想捕获关闭异常？得单独调用
fis.close()并自己 try-catch - 编译器不强制你处理 close 抛出的 checked exception，正是为了支持 try-with-resources 的简洁性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
