亲宝软件园·资讯

展开

Python asyncio的一个坑

灵剑 人气:0

我们先从一个常见的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代表大部分我们经常会在业务逻辑中处理到的异常,也包括一部分运行出错例如NameErrorAttributeError等等。但是并不是所有的异常都是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()之类代替。

加载全部内容

相关教程
猜你喜欢
用户评论