Python 异步迭代器的异常传播

async for 遇到异常时由外层 try/except 捕获，否则直接抛出导致崩溃；异步迭代器中异常不能被内部吞掉，应显式 raise stopasynciteration 或让其冒泡。

async for 遇到异常时，谁来捕获？

异步迭代器（__aiter__ / __anext__）抛出的异常不会自动“吞掉”，但也不会像同步 for 那样直接冒泡到外层作用域——它会被 async for 语句捕获并中止迭代，然后原样抛出。这意味着：你必须在 async for 外层用 try/except 捕获，否则程序就崩了。

常见错误现象：RuntimeError: async generator ignored GeneratorExit 或未处理的 ValueError、ConnectionError 导致协程静默退出或任务崩溃。

• 使用场景：比如用 aiohttp 流式读取分页 API，某次请求失败后 __anext__ 抛出 ClientError
• 不能依赖迭代器内部 try/except 吞掉异常并返回 StopAsyncIteration——这会掩盖真实问题，且违反 PEP 525
• 如果在 __anext__ 中手动 raise StopAsyncIteration，它不会被当作异常传播，而是正常终止循环

__annext__ 里 raise 和 return 的区别

__anext__ 必须返回一个 awaitable，而这个 awaitable 的结果决定了迭代行为：成功则返回值，失败则传播异常。关键点在于，你不能在 __anext__ 内部 return 异常对象，也不能 raise 后又试图“恢复”迭代。

示例中容易写错：

立即学习“Python免费学习笔记（深入）”；

async def __anext__(self):     try:         data = await self._fetch()         return data     except ConnectionError:         return None  # ❌ 错！这会让调用方收到 None，不是终止也不是报错

正确做法是让异常自然向上抛，或显式 raise StopAsyncIteration 终止：

async def __annext__(self):     try:         data = await self._fetch()         return data     except ConnectionError:         raise StopAsyncIteration  # ✅ 显式终止     # 或者不 catch，让 ConnectionError 直接冒泡

with async context manager 套 async for 时的异常顺序

如果异步迭代器本身是通过 async with 获取的（比如 async with aiofiles.open(...) as f:），那异常传播路径会多一层：资源清理逻辑（__aexit__）可能在迭代中途被触发，但它不会拦截 __anext__ 抛出的异常。

实际影响：

• __aexit__ 会在 async for 因异常中断后立即执行，但它的返回值（是否压制异常）只对它自己捕获的异常有效
• 若 __aexit__ 也抛异常（比如关闭连接失败），它会覆盖原始异常（python 默认行为），导致调试困难
• 建议在 __aexit__ 里尽量避免抛异常；如有必要，应记录原始异常并主动 re-raise，而不是靠返回 True 吞掉

测试异步迭代器异常传播的最小验证方式

别等集成环境出问题才查——用 asyncio.run() + 手动调用 __anext__ 最快定位问题。

实操建议：

• 绕过 async for，直接 await it.__anext__() 几次，观察第一次异常是否如预期抛出
• 用 pytest-asyncio 时，确保测试函数是 async def，且异常断言用 await pytest.raises(...)
• 注意事件循环状态：多次运行测试时，若迭代器内部持有了已关闭的 loop 或 client，可能报 RuntimeError: Event loop is closed

最易被忽略的是：异步迭代器的生命周期和其所依赖的异步资源（如 session、connection）必须严格对齐。异常没传出来，有时不是传播机制的问题，而是资源提前被回收、__anext__ 在一个无效上下文中执行了。