finally并非绝对可靠，其抛出的新异常会覆盖try/catch中的原异常；应通过addSuppressed()保留主异常并添加抑制异常，或优先使用try-with-resources。
在Java中，finally块常被误认为“绝对可靠”的清理兜底机制，但若未考虑异常传播路径与覆盖行为，反而可能掩盖真实错误、丢失关键异常信息。真正具备异常感知能力的finally逻辑，核心在于：不静默吞异常、不覆盖主流程异常、能区分并协同处理多种异常源。
明确finally的执行时机与异常覆盖风险
finally总会执行（除非JVM崩溃或调用System.exit()），但若其中抛出新异常，且try或catch块已有待抛出的异常，则原异常会被静默丢弃——这是最易踩的坑。
例如：
try {
throw new IOException("read failed");
} finally {
throw new RuntimeException("close failed"); // IOException被彻底覆盖
}
立即学习“Java免费学习笔记（深入）”；
解决思路不是避免finally抛异常，而是主动管理它：
- 在
finally中捕获自身操作可能抛出的异常（如close()） - 若
try块已发生异常，将finally中的异常作为抑制异常（suppressed exception）添加到主异常上 - 使用
Throwable.addSuppressed()（JDK7+）保留上下文完整性
用try-with-resources替代手工finally（推荐首选）
JDK7引入的try-with-resources语句天然支持异常感知：当资源关闭异常与主异常共存时，关闭异常自动作为抑制异常附加，主异常仍被抛出。
示例：
try (FileInputStream fis = new FileInputStream("data.txt")) {
int b = fis.read();
if (b == -1) throw new IllegalStateException("empty file");
} catch (IOException e) {
// 此处e可能是read异常，也可能是close时的IOException
// 若两者都发生，close异常会出现在e.getSuppressed()中
}
前提：资源类实现AutoCloseable接口（标准IO、JDBC等均已支持）。
手动finally中安全清理的三步写法
当无法使用try-with-resources（如需清理非AutoCloseable对象、或跨多个资源协调），应按以下结构编写finally：
- 声明一个局部
Throwable primaryException = null，在try外初始化 -
try块末尾不直接抛异常，而是捕获后赋值给primaryException，再throw或return -
finally中：先检查primaryException == null；若为null，正常清理并抛异常；否则，在catch中调用primaryException.addSuppressed(e)
这样既保留原始异常主导权，又不丢失清理失败线索。
日志与监控：让异常感知真正“可见”
即使逻辑正确，若无日志，抑制异常仍难排查。建议：
- 在
finally的catch块中记录警告日志，注明“资源清理失败”，并输出抑制异常堆栈 - 对关键资源（如数据库连接、网络通道），在清理失败时触发监控告警，而非仅依赖日志
- 避免在
finally中执行耗时或可能阻塞的操作（如远程调用、大文件写入），以防拖慢异常传播
