finally 中 throw 会彻底替换 try/catch 的异常，导致原始异常丢失；应优先使用 try-with-resources，其将关闭异常作为 suppressed exception 附加而不遮蔽。
finally 里 throw 会吃掉 try/catch 中的异常
Java 中，如果 try 或 catch 块已经抛出了异常，但 finally 块里又执行了 throw（或调用了会抛异常的方法），那么原始异常就彻底丢失了——JVM 只传播 finally 里的那个异常。
这不是“覆盖”，是直接替换：栈追踪里看不到原异常的任何痕迹，调试时会以为问题出在 finally 里，实际根源却被掩埋。
- 常见错误现象：
NullPointerException在try中发生，但日志只打印出IOException（来自finally关流），且无任何嵌套或提示 - 典型场景：资源关闭逻辑硬写在
finally里，比如手动close()一个可能已为null或已失效的InputStream - 参数/行为差异：无论
try中是return还是throw，只要finally有throw，就一定遮蔽前者
用 try-with-resources 替代手写 finally 关闭
这是最直接、最安全的解法。它把资源生命周期交给 JVM 管理，在异常传播路径上自动把“关闭失败”作为 suppressed exception 附加到主异常上，而不是抹掉它。
- 使用场景：所有实现了
AutoCloseable的资源，如FileInputStream、BufferedReader、Connection - 性能影响：几乎无额外开销；相比手写
finally，还省去空值判断和嵌套try - 兼容性：Java 7+，老项目升级时注意检查资源类是否真实现了
AutoCloseable（有些旧库只实现Closeable，但它是AutoCloseable子接口，没问题）
示例：
立即学习“Java免费学习笔记（深入）”；
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
return br.readLine();
} // 异常发生时，fis.close() 和 br.close() 自动触发，错误会被 suppress
如果必须手写 finally，别在其中 throw
手动管理资源时，finally 唯一该做的事是清理，不是报错。任何可能失败的操作（比如 close()）必须用内层 try-catch 吞掉异常，或至少记录但不抛出。
- 常见错误：直接写
resource.close();而不做空值/状态检查，导致NullPointerException或IOException遮蔽上游异常 - 正确做法：对每个 close 操作单独包一层
try-catch，且 catch 里只做log.warn或忽略 - 为什么不能
catch后再throw？一旦抛出，就又回到遮蔽问题——哪怕你 throw 的是同一个异常对象，JVM 也会视为新异常
示例（安全的手写 finally）：
FileInputStream fis = null;
try {
fis = new FileInputStream("a.txt");
return fis.read();
} finally {
if (fis != null) {
try {
fis.close();
} catch (IOException e) {
log.warn("failed to close fis", e); // 记录但不 throw
}
}
}
suppressedException 是线索，不是装饰
当用 try-with-resources 触发多异常时，主异常的 getSuppressed() 方法会返回被压制的异常数组。很多人忽略它，以为只是“附带信息”。
- 真实价值：它保留了资源关闭失败的完整上下文，包括堆栈——这往往是定位连接泄漏、文件句柄未释放的关键证据
- 容易踩的坑：日志框架默认不打印 suppressed 异常（Log4j 2.16+、SLF4J 2.0+ 才支持），用旧版 logback 或 log4j 1.x 时，必须手动遍历
getSuppressed()输出 - 调试建议：IDE 断点停在抛异常处，展开异常对象，点开
suppressedExceptions字段看有没有隐藏线索
遮蔽不是语法糖，是异常生命周期的硬规则。一旦 finally 抛异常，原异常就从 JVM 的异常传播链里被物理移除了——不是藏起来，是删掉了。
