为什么最终会阻止引发异常的返回[重复]答案

【问题标题】：Why does a return inside a finally block exceptions being raised [duplicate]为什么最终会阻止引发异常的返回[重复]
【发布时间】：2021-04-23 09:10:04
【问题描述】：

在 Python 3.6 中，从 finally 块返回会压缩所有未处理的异常 - 为什么？

例子：

def foo():
    print("Inside foo")
    raise ValueError("No good values supplied")
    print("Unreachable in foo")


def bar():
    print("Inside bar")
    try:
        foo()
        print("Unreachable in bar")
    finally:
        print("Finally block")
        return "A value"


print("Starting process")
res = bar()
print(f"Should be unreachable, because error is not handled - {res}")

如果finally 块没有返回，则异常正确地向上传播到堆栈

这个问题与Weird Try-Except-Else-Finally behavior with Return statements 不同，后者询问except 块的解析顺序，因为它是一个明确不处理代码的try 部分中引发的异常的构造。对代码的天真阅读，以及对 Python 原则的理解，例如“显式优于隐式”，会导致开发人员之前没有看到这种类型的构造，从而得出结论，当在 try 块中引发异常时， finally 会运行，但 return 将不起作用，因为异常未处理，因此会引发。但实际情况是，异常被隐式处理，函数成功返回到调用代码

【问题讨论】：

因为finally 块应该执行无论try 块是否引发异常，所以如果你在那里写return 这意味着你希望你的函数即使在@ 987654333@ 块引发异常。一个函数不能同时返回和引发，因此它不会引发。
不，这并不抱歉。它在问一个不同的问题。我的明确是关于try:、finally: 构造提升/不提升基于return 所在位置的概念。不过，该问题的答案之一中指向 PEP601 的链接很有用，谢谢
这个怎么样：Why doesn't finally: return propagate an unhandled exception?
是的，就是这样。它解释了行为，但未能解释为什么行为以这种方式存在。根据我的编辑，之前没有看到这种类型的构造的开发人员无法直觉（或者很可能会错误地直觉）行为
如果我理解正确，您的问题是关于 Python 语言设计者的意图？

标签： python python-3.x exception

【解决方案1】：

try 收集每个引发的异常。如果您想了解或对异常做出反应，则需要添加 except: 部分。您还可以指定要对 except ValueError: 做出反应的异常，并对此错误进行特定的错误处理。 finally 部分总是在最后被调用。这意味着要清理天气，try 部分是否运行成功。

【讨论】：