我们先从一个常见的Python编程错误开始说起，我已经见过非常多的程序员犯过这种错误了：
def do_not_raise(user_defined_logic):
try:
user_defined_logic()
except:
logger.warning("User defined logic raises an exception", exc_info=True)
# ignore
这段代码的错误之处在哪里呢？
我们从Python的异常结构开始说起。Python中的异常基类有两个，最基础的是BaseException，第二个是Exception（继承BaseException）。这两者有什么区别呢？
Exception代表大部分我们经常会在业务逻辑中处理到的异常，也包括一部分运行出错例如NameError、AttributeError等等。但是并不是所有的异常都是Exception类的子类，少数几个异常是继承于BaseException的：
- GeneratorExit
- SystemExit
- KeyboardInterrupt
第一个代表生成器被close()方法关闭，第二个代表系统退出（例如使用sys.exit），第三个代表程序被Ctrl+C中断。之所以它们并不继承于Exception，是因为：它们一般情况下绝不应当被捕获，或者被捕获之后应当立即reraise（通过不带参数的raise语句）。
如果写出上面那样的语句，就可能会出现程序无法退出的情况：从外部发送SIGTERM信号到程序，触发了SystemExit，然而SystemExit被捕获然后忽略了，这样程序就没有正常退出，而是继续执行下去。像SystemExit、KeyboardInterrupt、GeneratorExit这样的异常，因为没有固定的抛出位置，所以如果乱捕获的话非常危险，很可能产生隐含的bug，而且测试中会很难发现。这就是为什么Python官方文档上会强调，如果使用无参数的except，一定要配合raise重新将异常抛出。而正确的忽略执行异常的方法应该是：
def do_not_raise(user_defined_logic):
try:
user_defined_logic()
except Exception: ### <= Notice here ###
logger.warning("User defined logic raises an exception", exc_info=True)
# ignore
那么说了这么多，跟asyncio有什么联系呢？
在asyncio当中，一个异步过程可以通过asyncio.Task作为一个独立执行的单元启动，这个Task对象有一个cancel()方法，可以将它从中途强制停止。类似的，异步生成器也可以通过aclose()方法强制结束。当一个异步过程或者异步生成器被从外部强制中止的时候，会从当前的await或者yield语句抛出asyncio.CancelledError。
问题就出在这个CancelledError上！
asyncio也许是为了偷懒，也许是为了和concurrent一致，这个异常实际上是concurrent.futures.CancelledError。它的基类是Exception，而不是BaseException。要知道，在concurrent库当中，CancelledError是不会抛到已经开始了的子过程中的，它只会从future对象里抛出；而asyncio中，当使用了cancel()方法的时候，这个异常会从Task的当前堆栈位置抛出来。
这个事情就尴尬了，如果前面的do_not_raise是个异步方法，用 except Exception来捕获了用户自定义方法中的异常，那CancelledError也会被捕获到。结果就是CancelledError被错误地忽略掉，导致cancel()方法没有成功终止掉一个Task。
更尴尬的事情在于这个CancelledError的抛出机制。asyncio内部使用了Python的生成器和yield from机制，yield from可以自动代理异常，
为了说明这一点我们考虑下面的代码：
import traceback
import asyncio
async def func1():
try:
return await func2()
except Exception:
traceback.print_exc()
raise
async def func2():
try:
await asyncio.sleep(2)
except Exception:
traceback.print_exc()
raise
async def func3():
t1 = asyncio.ensure_future(func1())
await asyncio.sleep(1)
t1.cancel()
try:
await t1
except CancelledError:
pass
在t1.cancel()这里，会发生什么呢？实际上异常会从最内层的func2开始抛出，从func2抛出到func1，再到func3的await t1，所以可以看到两次traceback打印。
这就是异步方法中await的异常代理机制，它像同步调用一样，有完整的堆栈，并且异常从最内层抛出。这本身是一个很好的设计，很方便调试，但是一旦CancelledError抛出，你是无法确定它具体从哪条语句抛出的，这样在写异步逻辑的时候，实际上必须假设所有的await语句都有可能抛出CancelledError。如果在外面加上了前面的do_not_raise这样的机制，就会错误地忽略掉CancelledError。
所以异步逻辑中的忽略异常必须写成：
async def do_not_raise(user_defined_coroutine):
try:
await user_defined_coroutine
except CancelledError:
raise
except Exception:
logger.warning("User defined logic raises an exception", exc_info=True)
# ignore
这样才能保证CancelledError不被错误捕获。
从这个结果上来看，CancelledError从一开始就不应该继承自Exception，它应该是一个BaseException，这样就可以减少很多异步编程中的错误。
并不是自己不调用cancel()就不会出现这样的问题。一些会触发cancel()过程的常见例子包括：
asyncio.wait_for在执行超时的时候会自动cancel内部的过程，这是一个很常用的实现超时逻辑的方法
aiohttp的handler，如果没有处理完成之前用户就关闭了HTTP连接（比如强制点了浏览器的停止按钮），会对handler的异步过程调用cancel()
……
还有更尴尬的事情，许多时候我们不得不捕获CancelledError。刚才的一段代码，我故意没有提，读者们是否发现问题了呢？
t1.cancel()
try:
await t1
except CancelledError:
pass
在asyncio中，cancel()方法并不会立即结束一个异步Task，它只会抛出CancelledError，但是异步过程有机会使用except或者finally，在退出之前执行一些清理过程。这里的await的本意也是等待t1完全退出再继续。但是t1会抛出CancelledError，所以捕获这个异常，不让它再抛出。（而且如果不这么做，asyncio会打印一行warning，表示一个异步Task失败没有被处理）
那么问题就来了：如果func3()在执行到这里的时候，又被外部代码cancel()了呢？下面的except CancelledError就会变成问题，它会错误捕获外部的CancelledError。另外，t1也会再次被cancel一遍（没错，await一个Task的时候，如果await所在过程被cancel，Task也会被cancel，需要使用asyncio.shield来规避）
正确的写法应该是：
t1.cancel()
await asyncio.wait([t1])
try:
await t1
except CancelledError:
pass
asyncio.wait等待Task执行结束，但并不收集结果，因此内层的CancelledError不会在这里抛出来，而且如果此时取消func3，CancelledError并不会被忽略。第二个await t1时，t1可以保证已经结束，这里内部没有其他异步等待过程，因此CancelledError不会抛出在这里。也可以用t1.exception()之类代替。
到此这篇关于Python asyncio的一个坑的文章就介绍到这了,更多相关Python asyncio的一个坑内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
