我们先从一个常见的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
的:
第一个代表生成器被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()
之类代替。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:mmqy2019@163.com进行举报,并提供相关证据,查实之后,将立刻删除涉嫌侵权内容。
长按识别二维码并关注微信
更方便到期提醒、手机管理