在 Python 中使用 try-except-else 是一个好习惯吗？

R

Raymond Hettinger

“我不知道是不是因为无知，但我不喜欢那种编程，因为它使用异常来进行流控制。”

在 Python 世界中，使用异常进行流控制是常见且正常的。

甚至 Python 核心开发人员也使用异常来进行流控制，并且这种风格在语言中很重要（即迭代器协议使用 StopIteration 来表示循环终止）。

此外，try-except 样式用于防止某些 "look-before-you-leap" 构造中固有的竞争条件。例如，测试 os.path.exists 会导致信息在您使用时可能已经过时。同样，Queue.full 返回可能过时的信息。在这些情况下，try-except-else style 将生成更可靠的代码。

“我的理解是异常不是错误，它们应该只用于异常情况”

在其他一些语言中，该规则反映了他们的文化规范，正如他们的图书馆所反映的那样。 “规则”也部分基于这些语言的性能考虑。

Python 文化规范有些不同。在许多情况下，您必须对控制流使用异常。此外，在 Python 中使用异常不会像在某些编译语言中那样减慢周围代码和调用代码的速度（即 CPython 已经在每一步都实现了用于异常检查的代码，无论您是否实际使用异常）。

换句话说，您对“例外是为例外”的理解是在其他一些语言中有意义的规则，但对于 Python 则不然。

“但是，如果它包含在语言本身中，那肯定是有充分理由的，不是吗？”

除了有助于避免竞争条件外，异常对于将错误处理拉到循环外也非常有用。这是解释语言中的必要优化，这些语言往往不具有自动 loop invariant code motion。

此外，在处理问题的能力与问题出现的地方相去甚远的常见情况下，异常可以大大简化代码。例如，通常有顶级用户界面代码调用业务逻辑代码，而这些代码又调用低级例程。低级例程中出现的情况（例如数据库访问中唯一键的重复记录）只能在顶级代码中处理（例如要求用户提供与现有键不冲突的新键）。对这种控制流使用异常允许中级例程完全忽略该问题，并与流控制的这方面很好地分离。

有一个nice blog post on the indispensibility of exceptions here。

另外，请参阅此 Stack Overflow 答案：Are exceptions really for exceptional errors?

“try-except-else 存在的原因是什么？”

else 子句本身很有趣。它在没有例外但在 finally 子句之前运行。这是它的主要目的。

如果没有 else 子句，在最终确定之前运行附加代码的唯一选择就是将代码添加到 try 子句的笨拙做法。这很笨拙，因为它有可能在代码中引发不打算由 try 块保护的异常。

在最终确定之前运行额外的未受保护代码的用例并不经常出现。因此，不要期望在已发布的代码中看到很多示例。这有点罕见。

else 子句的另一个用例是执行在未发生异常时必须发生的操作，而在处理异常时不会发生的操作。例如：

recip = float('Inf')
try:
    recip = 1 / f(x)
except ZeroDivisionError:
    logging.info('Infinite result')
else:
    logging.info('Finite result')

另一个例子发生在单元测试运行器中：

try:
    tests_run += 1
    run_testcase(case)
except Exception:
    tests_failed += 1
    logging.exception('Failing test case: %r', case)
    print('F', end='')
else:
    logging.info('Successful test case: %r', case)
    print('.', end='')

最后，在 try 块中最常见的 else 子句用于美化（将异常结果和非异常结果对齐在同一缩进级别）。这种使用始终是可选的，并不是绝对必要的。

“这很笨拙，因为它有可能在代码中引发异常，而这些异常并不打算被 try-block 保护。”这是这里最重要的学习

In the Python world, using exceptions for flow control is common and normal.——我认为值得区分“Python 世界”和“CPython 核心开发者世界”。我研究过很多 Python 代码库，很少看到用于流控制的异常，并且看到许多 Python 开发人员不鼓励这种使用。

“else 子句的另一个用例是执行在未发生异常时必须发生的操作，而在处理异常时不会发生的操作。”这对我帮助很大。谢谢！

P

Peter Mortensen

try-except-else 存在的原因是什么？

try 块允许您处理预期的错误。 except 块应该只捕获您准备处理的异常。如果您处理意外错误，您的代码可能会做错事并隐藏错误。

如果没有错误，将执行 else 子句，并且通过不在 try 块中执行该代码，您可以避免捕获意外错误。同样，捕获意外错误可以隐藏错误。

例子

例如：

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else:
    return something

“try, except”套件有两个可选子句，else 和 finally。所以它实际上是 try-except-else-finally。

else 将仅在 try 块中没有异常时进行评估。它允许我们简化下面更复杂的代码：

no_error = None
try:
    try_this(whatever)
    no_error = True
except SomeException as the_exception:
    handle(the_exception)
if no_error:
    return something

因此，如果我们将 else 与替代方案（可能会产生错误）进行比较，我们会发现它减少了代码行数，并且我们可以拥有一个更具可读性、可维护性和错误更少的代码库。

最后

finally 无论如何都会执行，即使正在使用 return 语句评估另一行。

用伪代码分解

它可能有助于将其分解，以尽可能最小的形式展示所有功能，并附上注释。假设这个语法正确（但除非名称已定义，否则不可运行）伪代码在函数中。

例如：

try:
    try_this(whatever)
except SomeException as the_exception:
    handle_SomeException(the_exception)
    # Handle a instance of SomeException or a subclass of it.
except Exception as the_exception:
    generic_handle(the_exception)
    # Handle any other exception that inherits from Exception
    # - doesn't include GeneratorExit, KeyboardInterrupt, SystemExit
    # Avoid bare `except:`
else: # there was no exception whatsoever
    return something()
    # if no exception, the "something()" gets evaluated,
    # but the return will not be executed due to the return in the
    # finally block below.
finally:
    # this block will execute no matter what, even if no exception,
    # after "something" is eval'd but before that value is returned
    # but even if there is an exception.
    # a return here will hijack the return functionality. e.g.:
    return True # hijacks the return in the else clause above

确实，我们可以将 else 块中的代码包含在 try 块中，如果没有异常，它将在其中运行，但如果该代码本身引发异常怎么办？我们要抓的那种？将它留在 try 块中会隐藏该错误。

我们希望尽量减少 try 块中的代码行数，以避免捕获我们没有预料到的异常，原则是如果我们的代码失败，我们希望它大声失败。这是一个best practice。

我的理解是异常不是错误

在 Python 中，大多数异常都是错误。

我们可以使用 pydoc 查看异常层次结构。例如，在 Python 2 中：

$ python -m pydoc exceptions

或 Python 3：

$ python -m pydoc builtins

会给我们层次结构。我们可以看到大多数类型的 Exception 都是错误，尽管 Python 将其中一些用于结束 for 循环 (StopIteration) 之类的事情。这是 Python 3 的层次结构：

BaseException
    Exception
        ArithmeticError
            FloatingPointError
            OverflowError
            ZeroDivisionError
        AssertionError
        AttributeError
        BufferError
        EOFError
        ImportError
            ModuleNotFoundError
        LookupError
            IndexError
            KeyError
        MemoryError
        NameError
            UnboundLocalError
        OSError
            BlockingIOError
            ChildProcessError
            ConnectionError
                BrokenPipeError
                ConnectionAbortedError
                ConnectionRefusedError
                ConnectionResetError
            FileExistsError
            FileNotFoundError
            InterruptedError
            IsADirectoryError
            NotADirectoryError
            PermissionError
            ProcessLookupError
            TimeoutError
        ReferenceError
        RuntimeError
            NotImplementedError
            RecursionError
        StopAsyncIteration
        StopIteration
        SyntaxError
            IndentationError
                TabError
        SystemError
        TypeError
        ValueError
            UnicodeError
                UnicodeDecodeError
                UnicodeEncodeError
                UnicodeTranslateError
        Warning
            BytesWarning
            DeprecationWarning
            FutureWarning
            ImportWarning
            PendingDeprecationWarning
            ResourceWarning
            RuntimeWarning
            SyntaxWarning
            UnicodeWarning
            UserWarning
    GeneratorExit
    KeyboardInterrupt
    SystemExit

一位评论者问道：

假设您有一个 ping 外部 API 的方法，并且您想在 API 包装器之外的类中处理异常，您是否只需从 except 子句下的方法中返回 e，其中 e 是异常对象？

不，您不返回异常，只需使用裸露的 raise 重新引发它以保留堆栈跟踪。

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise

或者，在 Python 3 中，您可以引发新异常并使用异常链保留回溯：

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    raise DifferentException from the_exception

我在my answer here中详细说明。

赞成！你通常在手柄部分做什么？假设您有一个 ping 外部 API 的方法，并且您想在 API 包装器外部的类中处理异常，您是否只需从 except 子句下的方法中返回 e，其中 e 是异常对象？

@PirateApp 谢谢！不，不要返回它，你可能应该用一个空的 raise 再加注或进行异常链接 - 但这是更多的主题，在这里有介绍：stackoverflow.com/q/2052390/541136 - 我可能会在看到你之后删除这些评论'见过他们。

非常感谢您提供的详细信息！现在浏览帖子

j

jamylak

Python 不赞成只在异常情况下使用异常的想法，实际上成语是 'ask for forgiveness, not permission'。这意味着使用异常作为流程控制的常规部分是完全可以接受的，实际上是值得鼓励的。

这通常是一件好事，因为以这种方式工作有助于避免一些问题（作为一个明显的例子，经常避免竞争条件），并且它往往使代码更具可读性。

想象一下，您有一个需要处理的用户输入，但有一个已经处理的默认值。 try: ... except: ... else: ... 结构使得代码非常易读：

try:
   raw_value = int(input())
except ValueError:
   value = some_processed_value
else: # no error occured
   value = process_value(raw_value)

比较它在其他语言中的工作方式：

raw_value = input()
if valid_number(raw_value):
    value = process_value(int(raw_value))
else:
    value = some_processed_value

注意优点。无需检查值是否有效并单独解析，它们只完成一次。代码也遵循更合乎逻辑的进展，主要代码路径首先，然后是“如果它不起作用，请执行此操作”。

这个例子自然有点做作，但它表明这种结构是有案例的。

A

AbstProcDo

请参阅以下示例，该示例说明了有关 try-except-else-finally 的所有内容：

for i in range(3):
    try:
        y = 1 / i
    except ZeroDivisionError:
        print(f"\ti = {i}")
        print("\tError report: ZeroDivisionError")
    else:
        print(f"\ti = {i}")
        print(f"\tNo error report and y equals {y}")
    finally:
        print("Try block is run.")

实施它并通过：