如果在 finally 里也抛出了异常

finally中抛出的异常会覆盖try或except中的异常，成为最终传播的异常；应避免在finally中抛未处理异常，必要时用try捕获并记录；Python 3.11+可用ExceptionGroup保留两者。

在Python的异常处理流程中，finally块通常被视为可靠的“清道夫”。但这里有个关键细节需要特别注意：如果在 finally 块中抛出了异常，它会覆盖 try 或 except 中已发生的异常（如果有），成为最终向外传播的异常。 这意味着，无论前面发生了什么，最后抛出的那个“声音”最大的异常，才是程序最终报告的结果。

finally 中的异常会压制前面的异常

Python 的异常处理机制有一条明确的规则：只要 finally 块中主动抛出异常（或执行了引发异常的操作），这个新异常就会“取代”之前 try 或 except 中尚未处理完的异常。原异常的信息会被直接丢弃，调用栈中只会显示 finally 中抛出的那个异常。这就像一场接力赛，最后一棒选手的失误，会让团队之前的努力和成绩瞬间从记分牌上消失。

• 即使 try 中发生了异常并顺利进入了 except 块，只要后续的 finally 块抛出了异常，那么 except 块里的修复逻辑可能根本没机会执行完毕。
• 更有甚者，如果 except 块中已经执行了 return 语句，但 finally 块后续又抛出了异常，那么函数仍会以 finally 中的异常结束，之前的 return 会被“吞掉”。
• 来看一个典型的示例：
  

  >>> def f():
  ...     try:
  ...         raise ValueError("in try")
  ...     except ValueError:
  ...         print("caught")
  ...         return "from except"
  ...     finally:
  ...         raise RuntimeError("in finally")
  ...
  >>> f()
  caught
  Traceback (most recent call last):
    File "", line 1, in 
    File "", line 8, in f
  RuntimeError: in finally
  

  看到了吗？虽然 ValueError 被捕获了，也打印了“caught”，甚至执行了 return，但最终函数还是以 RuntimeError 崩溃告终。这就是 finally 异常的“压制”效果。

避免在 finally 中抛出未处理的异常

那么，如何规避这个陷阱呢？核心原则是：finally 的本意是确保清理逻辑一定执行，而不是用来做业务判断或执行可能失败的操作。 理想情况下，应该尽量让其中的代码“免疫”异常。

• 首先，把那些可能出错的操作移出 finally 块。如果它们必须执行，就放到 try/except 结构中提前处理掉。
• 其次，如果必须在 finally 中调用可能失败的方法（比如关闭文件、释放网络连接或锁），务必自行捕获其异常并妥善记录（例如记录到日志），而不是放任它传播出去，从而掩盖更重要的原始异常。
• 一个标准的防御性写法示例如下：
  

  finally:
      try:
          resource.close()
      except OSError as e:
          logging.warning(f"Failed to close resource: {e}")
          # 可以选择忽略或进行其他处理，但不再 raise
  

  这样一来，资源关闭的失败不会干扰主流程异常的传递，同时问题也被记录在案，便于后续排查。

需要同时保留两个异常时用 ExceptionGroup（Python 3.11+）

有没有一种情况，既需要在 finally 里执行可能失败的操作，又希望调用者能同时知道主业务异常和清理时的异常呢？在 Python 3.11 及更高版本中，可以使用 ExceptionGroup 来达成这个目的。

• 其思路是：显式地保存 try/except 中捕获的原始异常，然后当 finally 中发生异常时，手动将它们组合成一个 ExceptionGroup 再抛出。
• 不过，这种场景在实际开发中相对较少。多数情况下，最佳实践仍然是优先避免在 finally 中抛出未处理的异常。
• 需要提醒的是，这种方法会牺牲一定的代码可读性，并且依赖于较新的 Python 版本。如果项目需要兼容老版本 Python，则无法使用此特性。

总而言之，finally 块是保障代码健壮性的利器，但使用不当反而会引入隐蔽的 bug。牢记它的核心职责是“清理”，而非“决策”，并妥善处理其内部可能发生的异常，这样才能写出既稳定又易于调试的代码。