一种用法:测试一些应该引发异常的代码。

try:
    this_should_raise_TypeError()
except TypeError:
    pass
except:
    assert False, "Raised the wrong exception type"
else:
    assert False, "Didn't raise any exception"

(在实践中，这段代码应该被抽象为更通用的测试。)

try:
    statements # statements that can raise exceptions
except:
    statements # statements that will be executed to handle exceptions
else:
    statements # statements that will be executed if there is no exception

例子:

try:
    age=int(input('Enter your age: '))
except:
    print ('You have entered an invalid value.')
else:
    if age <= 21:
        print('You are not allowed to enter, you are too young.')
    else:
        print('Welcome, you are old enough.')

输出:

>>> 
Enter your age: a
You have entered an invalid value.
>>> RESTART
>>> 
Enter your age: 25
Welcome, you are old enough.
>>> RESTART
>>> 
Enter your age: 13
You are not allowed to enter, you are too young.
>>> 

复制自:https://geek-university.com/python/the-try-except-else-statements/

如果执行落在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都不会在这里被捕获

Try-except-else非常适合结合EAFP模式和duck-typing:

try:
  cs = x.cleanupSet
except AttributeError:
  pass
else:
  for v in cs:
    v.cleanup()

您可能认为naïve代码是好的:

try:
  for v in x.cleanupSet:
    v.clenaup()
except AttributeError:
  pass

这是在代码中意外隐藏严重错误的好方法。我在那里输入了清理，但是让我知道的AttributeError正在被吞噬。更糟糕的是，如果我写对了，但清理方法偶尔被传递一个具有错误命名属性的用户类型，导致它在中途无声地失败并留下一个未关闭的文件，会怎样?祝你在调试时好运。

查看Python引用，当没有异常时，else似乎在try之后执行。 当控制流出try子句的末尾时，执行可选的else子句。else子句中的异常不由前面的except子句处理。

Dive into python有一个例子，如果我理解正确的话，在try块中他们尝试导入一个模块，当失败时，你会得到异常并绑定默认值，但当它工作时，你可以选择进入else块并绑定所需的内容(参见示例和解释链接)。

如果你试图在catch块中工作，它可能会抛出另一个异常——我想这就是else块派上用场的地方。

我已经找到了…Else:在运行数据库查询并将这些查询的结果记录到相同风格/类型的单独数据库的情况下，构造非常有用。假设我有很多工作线程，它们都处理提交给队列的数据库查询

#in a long running loop
try:
    query = queue.get()
    conn = connect_to_db(<main db>)
    curs = conn.cursor()
    try:
        curs.execute("<some query on user input that may fail even if sanitized">)
    except DBError:
        logconn = connect_to_db(<logging db>)
        logcurs = logconn.cursor()
        logcurs.execute("<update in DB log with record of failed query")
        logcurs.close()
        logconn.close()
    else:

        #we can't put this in main try block because an error connecting
        #to the logging DB would be indistinguishable from an error in 
        #the mainquery 

        #We can't put this after the whole try: except: finally: block
        #because then we don't know if the query was successful or not

        logconn = connect_to_db(<logging db>)
        logcurs = logconn.cursor()
        logcurs.execute("<update in DB log with record of successful query")
        logcurs.close()
        logconn.close()
        #do something in response to successful query
except DBError:
    #This DBError is because of a problem with the logging database, but 
    #we can't let that crash the whole thread over what might be a
    #temporary network glitch
finally:
    curs.close()
    conn.close()
    #other cleanup if necessary like telling the queue the task is finished

当然，如果您能够区分可能抛出的异常，则不必使用这种方法，但是如果代码对成功的代码段的响应可能会抛出与成功的代码段相同的异常，并且您不能让第二个可能的异常消失，或者在成功时立即返回(在我的例子中，这会杀死线程)，那么这种方法就会派上用场。