finally块可能抛出异常时，如何避免异常隐藏？

当我们用try-catch-finally包裹业务流程时，如果finally块的操作也可能抛出异常，很容易出现异常隐藏的问题：如果try块和finally块都抛出异常，try块的异常会被覆盖，只有finally块的异常会向上传递。

存在异常隐藏问题的代码 #

try {
  // try块业务逻辑
  setupTestEnv();
  runTests();
} finally {
  // finally块清理操作
  cleanupTestEnv();
}

• 仅try块抛出异常时，finally块仍会执行清理，且try块的异常会正常向上抛出
• 若try块和finally块都抛出异常，try块的异常会被丢失/隐藏，只有finally块的异常会被传递到调用栈

修复方案的可行性与重抛方式分析 #

下面是针对该问题的一种修复代码，我们来逐一分析：

Throwable tryBlockException;
try {
  setupTestEnv();
  runTests();
} catch (Throwable t) {
  // 记录并抛出try块异常
  tryBlockException = t;
  throw t;
} finally {
   try {
      cleanupTestEnv();
   } catch (Throwable t) {
      if (tryBlockException != null) {
         // 若try块已有异常，将清理异常标记为被抑制异常
         tryBlockException.addSuppressed(t);
         throw tryBlockException;
      } else {
         // 只有清理异常时，直接抛出
         throw t;
      }
  }
}

方案可行性 #

这个方案完全可行，精准解决了异常隐藏的核心问题：

1. 通过tryBlockException变量留存try块抛出的异常，避免被finally块的异常覆盖
2. 借助Java的**被抑制异常（Suppressed Exception）**机制，将finally块的清理异常附加到try块的主异常上，既保留了所有异常信息，又确保了业务主异常的优先级

重抛异常的恰当性 #

这种重抛方式非常合理：

• 当try块和finally块都出现异常时，优先抛出try块的业务异常（这是引发问题的根源），同时通过addSuppressed()把清理异常附加进去，调试时可通过异常对象获取所有关键线索，不会丢失任何信息
• 当只有finally块抛出异常时，直接抛出该异常，符合清理操作失败的场景逻辑
• 注意：原方案中的throw ex是笔误，需修正为throw t才能正常编译

内容的提问来源于stack exchange，提问作者Peter Kahn