哦，你是对的。在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分钱。我必须跟在后面，清理许多由大学一年级的开发人员编写的代码，这些开发人员自认为很聪明，想以一种超级紧凑、超级高效的方式编写代码，但这样做只会让以后尝试和阅读/修改时变得一团糟。我每天都为可读性投票，周日两次。

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

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

如果没有错误，则执行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块中的代码行数，以避免捕获我们没有预料到的异常，原则是如果代码失败，我们希望它大声失败。这是一个最佳实践。

我的理解是异常不是错误

在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是异常对象吗?

不，您不返回异常，只是用一个简单的提升来重新提升它以保留堆栈跟踪。

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

我在这里详细说明我的答案。

你应该小心使用finally块，因为它与在try中使用else块不是一回事，除了。finally块将运行，而不管try的结果是什么。

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-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.

Python不赞同异常只用于异常情况的想法，事实上，习惯用法是“请求原谅，而不是许可”。这意味着使用异常作为流控制的常规部分是完全可以接受的，实际上是被鼓励的。

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

假设您有这样一种情况，需要处理一些用户输入，但默认值已经处理完毕。尝试:……除了:…其他:…结构使得代码可读性非常强:

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。这个功能封装在字典中。获得方法:

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

try/except块是一种视觉上更加混乱和冗长的方式，它可以用原子方法在一行中有效地执行。在其他情况下也是如此。

然而，这并不意味着我们应该避免所有的异常处理。在某些情况下，最好避免竞争条件。不要检查文件是否存在，只是尝试打开它，并捕获相应的IOError。出于简单性和可读性的考虑，请尝试将其封装或适当地提取出来。

阅读Python的禅宗，了解有一些原则处于紧张状态，并警惕过分依赖其中任何一条陈述的教条。