在Python中使用try-except-else是否是一种好习惯？

在Python中，我不时看到该块：

try:
   try_this(whatever)
except SomeException as exception:
   #Handle exception
else:
   return something

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

我不喜欢这种编程，因为它使用异常来执行流控制。但是，如果它包含在语言中，则一定有充分的理由，不是吗？

据我了解，异常不是错误，并且仅应将其用于特殊情况（例如，我尝试将文件写入磁盘，并且没有更多空间，或者我没有权限），而不是流控制。

通常，我将异常处理为：

something = some_default_value
try:
    something = try_this(whatever)
except SomeException as exception:
    #Handle exception
finally:
    return something

或者，如果发生异常，我真的不想返回任何东西，那么：

try:
    something = try_this(whatever)
    return something
except SomeException as exception:
    #Handle exception

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

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

甚至Python核心开发人员也将异常用于流控制，并且该样式已在语言中大量使用（即，迭代器协议使用StopIteration发出信号以终止循环）。

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

“据我了解，异常不是错误，它们仅应用于特殊情况”

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

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

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

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

除了帮助避免竞争条件外，异常对于在循环外拉出错误处理也非常有用。这是解释语言中的必要优化，这些语言通常不会具有自动循环不变的代码运动。

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

这里有一篇关于异常必不可少的不错的博客文章。

另外，请参见此堆栈溢出答案：异常真的是异常错误吗？

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

其他条款本身很有趣。它在没有例外的情况下运行，但是在最终条款之前。这是其主要目的。

如果没有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='')

最后，在尝试块中最常用的else子句是为了美化一些（在相同的缩进级别上对齐例外结果和非例外结果）。此用法始终是可选的，并非严格必要。

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

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

finally

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块中的代码行，以避免捕获我们未曾想到的异常，其原理是，如果我们的代码失败，我们希望它大声失败。这是最佳做法。

据我了解，异常不是错误

在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

有评论者问：

假设您有一个可对外部API进行ping的方法，并且想在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

我在这里详细回答。

Python不赞成将异常仅用于特殊情况的想法，实际上，习惯用法是“要求宽恕，而不是允许”。这意味着将异常作为流程控制的常规部分是完全可以接受的，并且实际上是受到鼓励的。

通常，这是一件好事，因为以这种方式工作有助于避免某些问题（显而易见的示例是，通常避免出现竞争条件），并且它倾向于使代码更具可读性。

假设您遇到这样一种情况，您需要处理一些用户输入，但是已经处理了默认输入。该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

注意优点。无需检查该值是否有效并单独对其进行分析，只需完成一次即可。代码也遵循更合理的顺序，首先是主代码路径，然后是“如果不起作用，请执行此操作”。

该示例自然有点虚构，但它显示了这种结构的情况。

在python中使用try-except-else是否是一种好习惯？

答案是它取决于上下文。如果您这样做：

d = dict()
try:
    item = d['item']
except KeyError:
    item = 'default'

它表明您不太了解Python。此功能封装在dict.get方法中：

item = d.get('item', 'default')

的try/ except块是写什么都可以有效地在一行用原子方法执行的视觉上更多混乱和冗长的方式。在其他情况下，这是正确的。

但是，这并不意味着我们应该避免所有异常处理。在某些情况下，最好避免比赛条件。不要检查文件是否存在，只需尝试将其打开，然后捕获相应的IOError。为了简单起见，请尝试将其封装或分解为适当的名称。

阅读Python的Zen，了解其中存在一些紧绷的原则，并且要警惕过于依赖其中任何一条语句的教条。

请参见以下示例，该示例说明了有关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.")

实施它并获得：

    i = 0
    Error report: ZeroDivisionError
Try block is run.
    i = 1
    No error report and y equals 1.0
Try block is run.
    i = 2
    No error report and y equals 0.5
Try block is run.

您应谨慎使用finally块，因为它与try中使用else块的功能不同，除了。无论try的结果如何，都将运行finally块。

In [10]: dict_ = {"a": 1}

In [11]: try:
   ....:     dict_["b"]
   ....: except KeyError:
   ....:     pass
   ....: finally:
   ....:     print "something"
   ....:     
something

正如所有人都指出的那样，使用else块会使您的代码更具可读性，并且仅在未引发异常时运行

In [14]: try:
             dict_["b"]
         except KeyError:
             pass
         else:
             print "something"
   ....:

每当您看到以下内容时：

try:
    y = 1 / x
except ZeroDivisionError:
    pass
else:
    return y

甚至这个：

try:
    return 1 / x
except ZeroDivisionError:
    return None

考虑一下这个：

import contextlib
with contextlib.suppress(ZeroDivisionError):
    return 1 / x

只是因为没有人发表过这一意见，我会说

避免使用else条款，因为大多数人都不熟悉这些条款try/excepts

与关键字try，except和和不同finally，该else子句的含义不言而喻。它的可读性较差。因为它不经常使用，所以它将导致阅读您的代码的人想要仔细检查文档，以确保他们了解正在发生的事情。

（我之所以写此答案，恰恰是因为我try/except/else在代码库中找到了a ，它导致了wtf时刻并迫使我进行了谷歌搜索）。

因此，无论我在哪里看到类似OP示例的代码：

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
else:
    # do some more processing in non-exception case
    return something

我宁愿重构为

try:
    try_this(whatever)
except SomeException as the_exception:
    handle(the_exception)
    return  # <1>
# do some more processing in non-exception case  <2>
return something

• <1>明确的回报清楚地表明，在例外情况下，我们已经完成工作

• <2>作为一个很好的次要副作用，该else块中的代码以前经过了一个级别的确定。

这是我关于如何理解Python中try-except-else-finally块的简单代码段：

def div(a, b):
    try:
        a/b
    except ZeroDivisionError:
        print("Zero Division Error detected")
    else:
        print("No Zero Division Error")
    finally:
        print("Finally the division of %d/%d is done" % (a, b))

让我们尝试div 1/1：

div(1, 1)
No Zero Division Error
Finally the division of 1/1 is done

让我们尝试div 1/0

div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done

OP，您是正确的。 在Python中try / except之后的else很难看。它导致另一个不需要的流控制对象：

try:
    x = blah()
except:
    print "failed at blah()"
else:
    print "just succeeded with blah"

完全清楚的等效项是：

try:
    x = blah()
    print "just succeeded with blah"
except:
    print "failed at blah()"

这比else子句清楚得多。try / except之后的else不经常编写，因此花一点时间弄清楚其含义是什么。

仅仅因为您可以做某事，并不意味着您应该做某事。

语言已经添加了许多功能，因为有人认为它可能派上用场。麻烦的是，功能越多，事物的清晰度和显而易见性就越差，这是因为人们通常不使用那些钟声和口哨声。

这里只有我的5美分。我必须走到后面，清理掉大学一年级开发人员写的很多代码，这些开发人员认为他们很聪明，并希望以超级严格，超级高效的方式编写代码，这只会使事情变得一团糟以尝试稍后阅读/修改。我每天对可读性进行投票，而星期日则两次。