你的生成器为何一 throw 就“猝死”？——生成器异常注入的防身术与掌控法则

你的生成器为何一 throw 就“猝死”？——生成器异常注入的防身术与掌控法则

在 Python 中，生成器的 throw() 方法是双向通信的三大支柱之一（另外两个是 send 和 close）。它允许调用方向生成器内部注入一个异常，就好像生成器暂停处的 yield 表达式主动抛出了那个异常一样。这个能力在协程调度、任务取消和错误传播中非常强大，但同时也极具破坏性：如果生成器内部没有捕获并处理这个异常，生成器就会当场终止，而且异常会沿着调用栈一路向上冒泡，让整个程序崩溃。

更隐蔽的是，很多开发者在调用 throw() 时，根本不知道生成器是否会处理、在何处处理，或者只是把它当作一个“远程终止”的粗暴手段，结果导致生成器清理失败、资源泄漏，甚至在 finally 块中引发二次异常，彻底掩盖了原始错误。今天，我们就来彻底拆解 throw() 的工作机制，解剖那些因异常处理失当而造成的惨案，并为你锻造一套从防御到反击的完整异常处理准则。

一、问题复现：轻轻一 throw，生成器灰飞烟灭

场景 1：未捕获异常，生成器直接崩溃

def worker():
    yield 1
    yield 2
    yield 3

w = worker()
print(next(w))   # 1
w.throw(ValueError, "出错了")
# ValueError: 出错了
# 生成器停止，无法再恢复
print(next(w))   # StopIteration (因为生成器已结束)

你在生成器产出 1 后，向它抛出了一个 ValueError。由于生成器内部没有任何 try...except，异常直接穿透生成器，把它彻底杀死。后续再尝试 next 只能得到 StopIteration，说明生成器已经关闭。

场景 2：处理异常后继续运行

def resilient():
    try:
        yield 1
    except ValueError:
        yield "恢复"
    yield 2

r = resilient()
print(next(r))           # 1
print(r.throw(ValueError)) # "恢复"
print(next(r))           # 2

这次生成器内部用 try 包裹了 yield，当 throw 注入 ValueError 时，异常被捕获，生成器继续产出 "恢复" 和 2。一切尽在掌控。

场景 3：在 yield from 委托中误伤子生成器

def sub():
    yield 'a'
    yield 'b'

def main():
    yield from sub()

m = main()
print(next(m))   # 'a'
m.throw(ValueError)
# ValueError 抛出，sub 未处理，传播到 main，main 也未处理，直接崩溃

你本意可能是向 main 注入异常，但 yield from 会将该异常透明地传递给子生成器 sub。如果 sub 没有防范，它先死，然后 main 也因为异常而终止。更糟糕的是，如果你期望 yield from 返回一个值，这个值将永远无法得到。

场景 4：用 throw 代替 close，清理代码失效

def important():
    try:
        yield 1
    finally:
        print("执行清理")

i = important()
next(i)
i.throw(RuntimeError)
# 输出："执行清理"
# 然后抛出 RuntimeError

throw 也会触发 finally 块，但它不像 close() 那样向生成器注入 GeneratorExit。如果你在 finally 中假设正常退出，可能做出错误判断。更危险的是，如果 finally 块中再次抛出异常，原始异常就会被覆盖。

二、底层原理：throw() 到底做了什么？

1. throw() 的三步操作

generator.throw(type[, value[, traceback]]) 的执行流程如下：

1. 在生成器暂停的位置“注入”异常：就像当前暂停的 yield 表达式引发了该异常。
2. 生成器内部处理：如果生成器内有 except 匹配了该异常，生成器会执行相应的处理代码，然后可以继续 yield 或 return。
3. 如果异常未被捕获：
   • 生成器被标记为关闭（状态变为 GEN_CLOSED）。
   • 该异常会从 throw 方法向上传播到调用方。

2. 与 next/send 的本质区别

• next()：向生成器发送 None 并恢复执行。
• send(value)：向生成器发送一个值并恢复执行。
• throw(exc)：向生成器发送一个异常并恢复执行。

换句话说，throw 就是将生成器的执行上下文从“等待一个值”变为“等待一个异常”。生成器必须显式使用 try 来捕获这个异常，否则就会像普通函数一样将该异常抛出。

3. yield from 的异常透明传递

yield from 的一大特性就是异常透明。当调用方对委托生成器使用 throw 时：

• 该异常会被直接传入子生成器的 throw 方法。
• 如果子生成器处理了异常并继续产出，则一切正常。
• 如果子生成器未处理，异常会传播回委托生成器，委托生成器也可以选择捕获。如果仍未捕获，异常继续向上冒泡。

这意味着，在使用 yield from 时，你必须清楚异常可能在哪里被处理，以及它最终是否会破坏你的生成器链。

三、常见陷阱与隐蔽的破坏力

陷阱 1：忘记处理导致生成器不可恢复

一旦生成器因未捕获异常而关闭，它就永久死亡了。如果你的程序依赖该生成器继续提供数据，后续的 next 或 send 只会引发 StopIteration。更糟糕的是，你可能会把这种“静默终止”误认为是正常结束。

陷阱 2：在 finally 中执行 yield 或再次抛出异常

def bad():
    try:
        yield 1
    finally:
        yield 2  # 非法！Python 3 不允许在 finally 中 yield

虽然 Python 3 禁止在 finally 中使用 yield，但你可以通过其它方式（比如在 finally 中 return）继续执行。但关键是，如果你在 finally 块中引发了新异常，原始异常信息可能丢失，极大增加调试难度。

陷阱 3：用 throw 传递控制信号而忽略异常类型

你可能想用 throw(StopIteration) 来提前终止生成器，但在 Python 3.7+ 中，生成器内部手动引发的 StopIteration 会被转换成 RuntimeError。这意味着你永远不应该向生成器内部注入 StopIteration。正确的终止方式是用 close()。

陷阱 4：throw 后未检查生成器状态，盲目继续操作

g.throw(ValueError)
# 没有检查异常是否被处理
print(next(g))  # 可能抛出 StopIteration

安全做法是：如果你不打算让生成器终止，就应该确保它内部已经处理了该异常，或者在调用 throw 后捕获可能冒泡的异常并做出反应。

陷阱 5：在协程或任务调度中滥用 throw 进行取消

虽然 asyncio.Task.cancel() 底层就是通过 throw 注入 CancelledError，但如果你手动 throw 一个非标准异常去取消协程，可能会导致协程跳过重要的清理逻辑，或者未被妥善捕获而引发不必要的错误报告。始终使用标准的 close() 或框架提供的取消机制。

四、正确使用 throw 的几大模式

模式一：生成器内部显式捕获预期异常

这是最基础也最安全的做法：在生成器内部用 try...except 包围可能被注入异常的 yield 语句，并决定是继续运行、产出错误信息还是优雅退出。

def controlled():
    try:
        while True:
            x = yield
            print(f"收到: {x}")
    except ValueError:
        print("值错误，即将关闭")
        return  # 正常关闭
    except GeneratorExit:
        print("收到关闭信号，清理中...")
        raise   # 必须重新抛出，否则生成器不会真正关闭

关键：对于 GeneratorExit，必须重新 raise，否则生成器无法正确关闭（Python 会强制抛出 RuntimeError）。

模式二：利用 throw 实现带外控制信号

你可以和生成器约定一套“控制异常”，比如 class Abort(Exception): pass。当外部需要取消生成器时，注入 Abort，生成器捕获它并执行特定的收尾工作。

class Abort(Exception):
    pass

def task():
    try:
        while True:
            yield "工作中"
    except Abort:
        print("任务被取消")
        return "已取消"

调用方：

t = task()
print(next(t))       # "工作中"
t.throw(Abort)       # 输出 "任务被取消"，生成器正常结束（StopIteration 携带返回值）

模式三：在 yield from 中隔离异常

如果你希望在委托生成器中捕获子生成器的异常，可以在 yield from 外面套一层 try。

def main():
    try:
        yield from sub()
    except ValueError:
        print("子生成器遇到值错误，主生成器接手处理")
        yield "处理完毕"

这样即使 sub 未能处理 ValueError，main 也不会崩溃，而是有机会接盘。

模式四：使用 close() 而非 throw 进行标准关闭

如果你只是想终止生成器，永远使用 close()。close() 注入 GeneratorExit，生成器内的 finally 块会得到执行，且生成器不能忽略 GeneratorExit（必须重新抛出或自然退出）。这样可以确保资源得到释放。

模式五：结合 send 和 throw 构建健壮协程

在经典的“生产者-消费者”协程中，可以通过 throw 传递错误信息，让消费者处理异常后继续运行，而不是整条链断开。

def consumer():
    while True:
        try:
            item = yield
            # 处理 item
        except ValueError:
            print("非法数据，跳过")
            continue

五、调试与状态检查

1. 使用 inspect.getgeneratorstate 跟踪状态：在注入异常前后检查，确认生成器是否进入 GEN_CLOSED。
2. 捕获 throw 可能冒泡的异常：在调用 throw 的外围包裹 try...except，记录日志或恢复操作。
3. 在生成器内部增加调试日志：尤其是 except 块中打印异常类型，确认异常被正确路由。
4. 单元测试覆盖异常场景：测试生成器在接收各种异常时的行为，包括未处理异常、处理异常、以及 GeneratorExit。
5. 静态分析：pylint 等工具无法直接检测 throw 的异常处理，但代码审查时应检查每个 yield 是否被适当的 try 保护。

六、最佳实践总结

• 永远在需要接收异常的生成器中使用 try...except 包围 yield。
• 不要用 throw 注入 StopIteration，使用 return 结束生成器。
• 使用 close() 而不是随意 throw 来终止生成器。
• 在 yield from 链中明确异常处理职责：要么子生成器处理，要么委托生成器兜底。
• 处理 GeneratorExit 时必须重新抛出，否则生成器无法正常关闭。
• 为生成器编写清晰的文档，声明它支持哪些异常注入，以及各自的响应。
• 在复杂协程中，考虑使用 asyncio 等高级框架，它们提供了更安全的取消和异常传播机制。
• 调试时利用 throw 注入自定义异常来模拟故障，验证生成器的容错性。

七、结语

throw() 是 Python 生成器赋予我们的一把双刃剑：它能将外部世界的错误精确地注入到协程最深处，实现精细化的流程控制；但若不加防护，它也会瞬间将生成器砍成两半，留下资源泄漏和未处理的烂摊子。理解 throw 的核心，不在于记住它能抛异常，而在于认识到异常必须由生成器内部消化——就像一扇门，你可以把信递进去，但必须有人在门后接应。在每一次生成器的 yield 周围筑起 try 的围墙，为每一个可能的异常指定归宿，你的生成器才能真正变成可靠的异步管道，而非一触即溃的空中楼阁。