在 try-catch-finally 中，finally 抛出异常或执行 return 会覆盖或吞掉原始异常，导致问题难以定位；应优先使用 try-with-resources，否则需在 finally 中捕获异常并用 addSuppressed 关联主异常。
在 try-catch-finally 结构中，异常可能被“隐藏”——不是因为没捕获，而是后续代码（尤其是 finally 块）覆盖或压制了原始异常，导致真正出问题的地方难以定位。这是 Java 异常处理中最容易被忽视的陷阱之一。
finally 中抛出异常会覆盖 try/catch 中的异常
如果 try 或 catch 块已抛出异常，但 finally 块又主动抛出另一个异常，那么前一个异常将**完全丢失**，JVM 只会传播 finally 中的新异常。
- 例如：
try中发生NullPointerException，进入catch记录日志后正常返回；但finally中调用了一个必然失败的 close() 方法并抛出IOException——最终堆栈里只看到IOException，原始空指针问题被掩盖。 - 关键点：只要
finally执行时抛出了未捕获的异常，它就会成为方法最终抛出的异常，无论之前发生了什么。
finally 中 return 语句会吞掉异常
finally 块中使用 return 不仅会中断异常传播，还会直接返回值，使 try 或 catch 中的异常彻底失效。
- 示例：方法声明为
throws IOException，try中抛出该异常，但finally末尾写了return 42;——方法安静返回 42，异常不会上抛，调用方完全感知不到错误。 - 这种写法违反异常设计初衷，属于隐蔽的逻辑错误，应严格禁止。
安全释放资源：用 try-with-resources 替代手动 finally
JDK 7 引入的 try-with-resources 能自动关闭实现了 AutoCloseable 的资源，并在多个异常发生时将“主异常”作为抛出异常，“被抑制异常”通过 getSuppressed() 获取，避免隐藏。
立即学习“Java免费学习笔记（深入）”；
- 对比传统写法：
FileInputStream fis = null; try { fis = new FileInputStream(...); ... } finally { if (fis != null) fis.close(); }——close() 失败会覆盖主异常。 - 推荐写法：
try (FileInputStream fis = new FileInputStream(...)) { ... }——即使读取和关闭都出错，读取异常为主异常，关闭异常会被抑制并保留可查。
必须在 finally 中处理异常时：显式捕获并抑制
若因兼容性等原因无法用 try-with-resources，且 finally 中的操作（如 close）可能失败，应明确捕获其异常，并用 addSuppressed() 关联到主异常。
- 步骤：先保存主异常（如从 catch 块中），在 finally 中捕获资源关闭异常，再调用
primaryException.addSuppressed(closeException)。 - 注意：仅当主异常非 null 时才调用
addSuppressed，否则会抛NullPointerException。
