finally抛异常会覆盖原始异常，应删掉throw语句、避免return，清理失败需用try-catch捕获并addsuppressed挂载，优先使用try-with-resources自动处理。
Java中finally块抛异常会直接覆盖try或catch里的原始异常，导致原始错误信息彻底丢失——这不是bug，是JVM规范行为。关键不是“能不能”，而是“怎么留痕、不丢根”。
别让finally自己throw
finally的职责是清理，不是报错。任何显式 throw、return 或 System.exit() 都会中断异常传播链。
- 删掉 finally 中所有 throw new XxxException() 语句
- 避免 return result; 这类写法，哪怕方法是 void 的 return; 也不行
- 若清理逻辑可能失败（如 close() 抛 IOException），必须用 try-catch 包住，只记录日志，不向外抛
用 addSuppressed 主动挂载清理异常
当原始异常已在 catch 中捕获，你可以在 finally 里捕获清理异常，并把它作为“被抑制异常”附加到原始异常上。
- 在 catch 块中保留对原始异常的引用（例如 Exception e = ex;）
- finally 中对 close() 等操作加 try-catch，捕获到 cleanupEx 后调用 e.addSuppressed(cleanupEx)
- 最后在方法末尾 throw e；调用方可通过 getSuppressed() 查看完整上下文
优先改用 try-with-resources
这是最简洁、最安全的现代写法，编译器自动处理资源关闭，并原生支持 suppressed 异常机制。
- 资源类型必须实现 AutoCloseable（InputStream、Connection、Scanner 等均满足）
- 即使 try 块抛出异常，且 close() 也抛异常，主异常仍为 try 中的异常，close 异常自动成为 suppressed
- 无需手写 finally，也无需手动 addSuppressed，代码更短、语义更清晰
哪些清理操作最容易踩坑
这些模式高频引发异常丢失，检查代码时重点盯：
- 手动调用 inputStream.close()、connection.close()，且未判空或没包 try
- finally 中调用自定义 releaseResource()，内部含网络/文件IO
- 日志框架 shutdown() 或 flush() 放在 finally 里，而它们可能抛 InterruptedException
- 旧式 JDBC 管理中，finally 关闭 Connection 前没检查是否为 null
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
