是，finally块抛异常会直接覆盖try/catch中的原始异常；这是JVM规范行为，原异常被丢弃，仅传播finally中的新异常，但可通过addSuppressed()和getSuppressed()手动维护异常链。
finally块中抛出异常会直接覆盖try或catch中已发生的原始异常，导致原始错误信息丢失。这不是bug，而是JVM异常传播机制的明确行为：当finally执行throw时，它成为方法最终抛出的异常，原异常被丢弃。但Java提供了标准机制来保留上下文——通过addSuppressed()和getSuppressed()维护异常链。
为什么原始异常会被覆盖
在字节码层面，JVM对异常的处理是“后抛先得”：try中抛出的异常只是暂存，尚未真正传播；一旦finally也抛出异常，JVM就将其视为当前方法最新的、必须传播的异常。原异常因无引用而被GC回收，物理上消失。这使得日志里只看到“关闭连接失败”，却看不到“SQL语法错误”这个真正原因。
手动维护异常链的正确写法
若必须手写finally（如旧项目无法改用try-with-resources），需显式保存原始异常并压制清理异常：
- 在catch中用局部变量持有原始异常（例如
Exception original = e;） - 在finally内对close等操作加独立try-catch
- 若清理操作抛异常，调用
original.addSuppressed(cleanupEx) - 最后统一
throw original;
调用方拿到该异常后，可通过 e.getSuppressed() 获取所有被压制的异常数组，还原完整故障链。
立即学习“Java免费学习笔记（深入）”；
优先使用try-with-resources替代手写finally
这是最简洁、最安全的现代方案，编译器自动完成三件事：
- 资源声明即绑定生命周期，自动在作用域结束时调用
close() - 若try块抛异常A，且
close()抛异常B，则A为主异常，B自动成为suppressed - 无需判空、无需嵌套try、无需手动
addSuppressed()，语义清晰
前提是资源类型实现AutoCloseable——InputStream、Connection、Scanner等标准类均已满足。
哪些清理操作最容易引发异常丢失
以下模式是代码审查时的重点雷区：
- 手动调用
inputStream.close()或connection.close()，且未判空或未包裹try-catch - 自定义
releaseResource()方法放在finally中，内部含文件/网络IO逻辑 - 日志框架的
shutdown()或flush()调用在finally里，可能抛InterruptedException - JDBC旧式管理中，finally关闭
Connection前未检查是否为null
