finally中throw会替换原始异常并将其作为suppressed exception保留，return则无条件覆盖try/catch的返回值；二者均违背finally仅用于资源清理的设计本意。

Java 中 try-catch-finally 的异常覆盖现象，本质不是“异常被吞掉”，而是控制流与返回值语义的叠加效应。真正需要警惕的，是 finally 块中主动 throw 异常或 return 语句对原始异常/返回值的终结性覆盖。

finally 中 throw 会彻底替换原始异常

当 try 或 catch 已抛出异常，但 finally 块中又 throw 新异常时，原始异常会被丢弃，调用方只能看到 finally 抛出的那个异常——原始异常不会丢失，而是作为 suppressed exception（被抑制异常）保留在新异常对象中，可通过 getSuppressed() 获取。

• try 抛出 IOException → catch 捕获并处理 → finally 中 throw new RuntimeException("cleanup failed") → 外部捕获到的是 RuntimeException，原 IOException 被抑制
• 若 finally 中未捕获 close() 异常就直接 throw，会导致资源清理失败的错误掩盖业务逻辑错误，排查困难

finally 中 return 会无条件覆盖 try/catch 的返回值

这是最隐蔽也最常被误用的行为：只要 finally 写了 return，无论 try 或 catch 是否已有 return，最终方法一定返回 finally 的值，且原始返回值或异常完全失效。

• 危险示例：try 中 return "success";，finally 中 return "finally wins"; → 实际返回 "finally wins"
• 这种写法编译通过，但违反 finally 的设计本意——它应只做清理，不参与业务决策
• JVM 执行逻辑是：快照 try/catch 的返回值 → 强制执行 finally → 遇到 return 就立即退出方法，不再回传快照值

资源释放过程中异常覆盖的典型场景

手动管理资源（如流、连接）时，close() 自身可能抛异常，若处理不当，就会发生异常覆盖：

立即学习“Java免费学习笔记（深入）”；

• try 块读文件失败抛出 FileNotFoundException
• finally 中调用 fis.close() 又抛 IOException → 外部看到的是后者，前者被掩盖
• 正确做法：在 finally 的 close() 外层加独立 try-catch，仅记录错误，不 throw；或使用 try-with-resources，它会自动将 close 异常添加为 suppressed，保留主异常

规避覆盖的实用策略

核心原则是分离关注点：业务逻辑与异常传播在 try/catch 中完成，finally 只做无副作用的清理。

• 永远不在 finally 中写 return 或 throw
• 资源关闭前先判空（if (resource != null)），避免 NullPointerException 掩盖原始异常
• 优先使用 try-with-resources（Java 7+），它能确保 close() 执行，并智能处理多重异常抑制
• 若必须手写 finally，关闭操作要包裹在独立 try-catch 中，且不向上抛出