Python asyncio的一个坑

时间:2022-05-23 灵剑人气: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代表大部分我们经常会在业务逻辑中处理到的异常，也包括一部分运行出错例如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()之类代替。

加载全部内容