finally中抛出异常会覆盖try/catch中的异常，导致原异常堆栈信息丢失；应优先使用try-with-resources自动抑制close异常，或在手动finally中用try-catch处理close并addsuppressed。
finally 中抛出异常会覆盖 try/catch 中的异常
这是 Java 异常处理中最容易被忽略的覆盖行为：只要 finally 块中执行了 throw 或发生了未捕获异常，它就会“吃掉” try 或 catch 中已经抛出的异常。JVM 只向调用方传递 finally 中的异常，原异常的堆栈信息完全丢失。
-
try抛出NullPointerException，catch捕获并记录后准备 re-throw，但finally中调用close()时抛出IOException→ 最终抛出的是IOException，NPE 被静默丢弃 - 即使
catch块里写了throw e，只要finally有异常，它就赢 - 该行为在所有 Java 版本中一致（包括 Java 7+ 的 try-with-resources），不是 bug，是规范定义
用 try-with-resources 替代手动 finally 关闭资源
Java 7 引入的 try-with-resources 不仅语法简洁，更重要的是它**自动抑制（suppressed）了 close() 中的异常**，确保原始异常不被覆盖。
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader reader = new BufferedReader(new InputStreamReader(fis))) {
return reader.readLine();
} catch (IOException e) {
// 这里捕获的是 readLine() 抛出的异常
// 即使 close() 失败，异常会被 suppress 并附加到主异常上
throw new RuntimeException("读取失败", e);
}
- 要求资源类实现
AutoCloseable接口（Closeable是其子接口） - 多个资源按声明顺序初始化，按**逆序**关闭；任一
close()抛异常都会被 suppress，不会中断主异常流程 - 可通过
e.getSuppressed()获取被抑制的异常数组，用于日志或诊断
手动 finally 中需显式处理 close 异常
如果因兼容性或逻辑必须手写 finally（比如资源创建不在 try 内、或需条件关闭），就不能直接在 finally 里裸调 close()。
InputStream is = null;
try {
is = new FileInputStream("a.txt");
return doSomething(is);
} catch (IOException e) {
log.error("处理失败", e);
throw e;
} finally {
if (is != null) {
try {
is.close(); // 必须套一层 try-catch
} catch (IOException e) {
log.warn("关闭流失败，忽略", e); // 或聚合到主异常
}
}
}
- 绝不能让
close()的异常逃出finally块 - 若需保留 close 异常信息，可将其作为 suppressed 异常添加到主异常：
originalException.addSuppressed(closeException) - 注意：只有
Throwable子类（如Exception、Error）支持addSuppressed()，且主异常不能为null
不要在 finally 中 return 或 throw（除非你明确知道后果）
finally 中的 return 或 throw 会强行终止当前方法执行流，导致 try/catch 中的 return 或 throw 失效 —— 这比异常覆盖更隐蔽，且难以调试。
立即学习“Java免费学习笔记（深入）”；
- 函数返回值会被
finally中的return覆盖，连日志都可能来不及打 -
throw在finally中等价于“无条件中断”，原有控制流和异常语义全部作废 - 唯一合理使用场景：资源清理失败且必须立即终止（极少见），否则一律避免
真正关键的不是“能不能写”，而是“有没有意识到它会切断整个异常链”。一旦 finally 出了问题，原始错误就再也找不回来了。
