else块通常可以用来补充出现在每个except块中的功能。

try:
    test_consistency(valuable_data)
except Except1:
    inconsistency_type = 1
except Except2:
    inconsistency_type = 2
except:
    # Something else is wrong
    raise
else:
    inconsistency_type = 0

"""
Process each individual inconsistency down here instead of
inside the except blocks. Use 0 to mean no inconsistency.
"""

在这种情况下，在每个except块中设置inconsistency_type，以便在无错误情况下在else中补充行为。

当然，我将此描述为某一天可能会出现在您自己的代码中的模式。在这个特定的情况下，您只要在try块之前将inconsistency_type设置为0即可。

就是这样。try-except子句中的'else'块用于当(且仅当)被试操作成功时运行的代码。它可以被利用，也可以被滥用。

try:
    fp= open("configuration_file", "rb")
except EnvironmentError:
    confdata= '' # it's ok if the file can't be opened
else:
    confdata= fp.read()
    fp.close()

# your code continues here
# working with (possibly empty) confdata

就我个人而言，我喜欢它，并在适当的时候使用它。它在语义上对语句进行分组。

我能想到的一种使用场景是不可预测的异常，如果您再次尝试，可以避免这种异常。例如，当try块中的操作涉及随机数时:

while True:
    try:
        r = random.random()
        some_operation_that_fails_for_specific_r(r)
    except Exception:
        continue
    else:
        break

但是如果可以预测异常，则应该始终在异常之前选择验证。然而，并不是所有的事情都可以预测，所以这种代码模式有它的一席之地。

我发现它非常有用，当你有清理工作要做，即使有例外:

try:
    data = something_that_can_go_wrong()
except Exception as e: # yes, I know that's a bad way to do it...
    handle_exception(e)
else:
    do_stuff(data)
finally:
    clean_up()

也许它的用法是:

#debug = []

def debuglog(text, obj=None):
    " Simple little logger. "
    try:
        debug   # does global exist?
    except NameError:
        pass    # if not, don't even bother displaying
    except:
        print('Unknown cause. Debug debuglog().')
    else:
        # debug does exist.
        # Now test if you want to log this debug message
        # from caller "obj"
        try:
            if obj in debug:
                print(text)     # stdout
        except TypeError:
            print('The global "debug" flag should be an iterable.')
        except:
            print('Unknown cause. Debug debuglog().')

def myfunc():
    debuglog('Made it to myfunc()', myfunc)

debug = [myfunc,]
myfunc()

也许这对你也有帮助。

如果执行落在try的底部(如果没有异常)，else块中的语句将被执行。说实话，我从来没有找到过需要。

然而，处理异常注意到:

使用else子句更好 而不是向try中添加额外的代码 因为它避免意外 捕获非异常 由被保护的代码引发 尝试…除了声明。

因此，如果你有一个方法，例如，抛出一个IOError，你想捕捉它引发的异常，但如果第一个操作成功，你还想做其他事情，而你不想从那个操作中捕获IOError，你可能会写这样的东西:

try:
    operation_that_can_throw_ioerror()
except IOError:
    handle_the_exception_somehow()
else:
    # we don't want to catch the IOError if it's raised
    another_operation_that_can_throw_ioerror()
finally:
    something_we_always_need_to_do()

如果您只是在operation_that_can_throw_ioerror()后面加上另一个other_operation_that_can_throw_ioerror()， except将捕获第二次调用的错误。如果你把它放在整个try块之后，它会一直运行，直到finally之后。else可以让你确定

第二次操作只有在没有例外的情况下才会进行， 它在最后一个块之前运行，并且 它引发的任何ioerror都不会在这里被捕获