finally块中抛出异常会覆盖try或catch中的原始异常，导致原始异常丢失；应通过addsuppressed()手动关联或优先使用try-with-resources来保留异常信息。
在 Java 中，finally 块中抛出异常会覆盖 try 或 catch 中已发生的异常，导致原始异常丢失 —— 这是容易被忽视但影响调试的关键行为。
finally 抛异常会吞掉原异常
当 try 块中发生异常（比如 NullPointerException），且该异常未被 catch 捕获，或即使被捕获后 finally 又抛出新异常（如 IOException），JVM 会丢弃原始异常，仅将 finally 中的异常向上抛出。调用栈里看不到最初出问题的地方。
- 原始异常对象不会自动添加为 suppressed exception（不像 try-with-resources 中的资源关闭异常）
- 除非手动调用
addSuppressed()，否则无痕迹可循 - 日志或 IDE 调试时只看到 finally 的异常，排查成本陡增
如何保留原始异常信息
若必须在 finally 中做可能失败的操作（如关闭资源、记录日志），应主动保存并关联原始异常：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 在
catch块中捕获原始异常，赋值给局部变量（如Throwable cause = e;） - 在
finally中捕获新异常，并用addSuppressed(cause)将其附加到新异常上 - 或者更推荐：改用 try-with-resources，让编译器自动处理资源关闭异常的压制逻辑
常见误用场景
以下写法看似合理，实则危险：
- 在
finally中直接调用可能抛异常的方法（如outputStream.close()），却不做任何异常处理 - 用
return+finally组合，同时又在finally里 throw 异常，导致返回值失效且异常被掩盖 - 认为 “
finally总是执行” 就等于 “finally安全”，忽略了它本身也可能成为异常源
替代方案优先级建议
减少 finally 抛异常风险的最佳实践：
- 优先使用 try-with-resources 管理可关闭资源，它自动抑制关闭异常
- 若需手动清理，把高风险操作放在
catch块中，而非finally - 实在要在
finally中抛异常，务必捕获并压制原始异常，再重新抛出 - 单元测试中模拟
finally异常路径，验证异常链是否完整
不复杂但容易忽略：异常流的完整性，往往取决于你是否记得在 finally 里“留个口子”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
