生成器内部yield抛出的异常会直接传递给调用方，不会被函数体外层try/except捕获；需在调用侧处理或在yield附近用try/except容错，也可用throw()主动注入异常。
生成器内部抛出异常会被next()或send()直接抛出
生成器函数里 yield 执行期间如果发生异常（比如除零、键不存在、类型错误），不会被生成器自己“吞掉”，而是会中断当前 yield，并把异常原样抛给调用方——也就是触发 next()、send() 或进入 for 循环的那层代码。
这意味着你不能靠在生成器函数体外套 try/except 来捕获它内部 yield 时的错误；必须在调用侧处理。
-
for x in gen:遇到异常会直接中断循环，并把异常冒泡上去 -
next(gen)抛异常后，该生成器对象状态变为EXHAUSTED，后续再调用会报StopIteration - 如果用
gen.send(value)，异常同样在 send 返回前抛出，生成器停在出错的yield表达式处（未完成本次 yield）
在生成器内部用try/except包围yield语句本身
如果你想让生成器“自己消化”某些异常、不中断执行、甚至继续产出后续值，就得把 yield 放进 try/except 块里——注意：不是包整个函数体，而是包住每次可能出问题的 yield 行或其前置逻辑。
def safe_divide(dividends, divisors):
for a, b in zip(dividends, divisors):
try:
yield a / b
except ZeroDivisionError:
yield float('inf') # 或 None, 或跳过
这种写法下，单次 yield a / b 出错不会终止生成器，它会走 except 分支再继续下一轮循环。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 适用于需要容错、降级、打日志但不希望生成器提前结束的场景
- 不能捕获在
yield之后、下一次yield之前的普通语句异常（比如循环末尾的append()错误），那些仍会中止生成器 - 若在
except中又抛新异常，且没被再次捕获，那新异常仍会向上冒泡
用generator.throw()主动向生成器注入异常
这是最易被忽略的机制：生成器对象提供 throw() 方法，允许外部代码在生成器暂停点（即某个 yield 处）强行抛出指定异常。生成器收到后，会从那个 yield 表达式位置开始执行异常处理逻辑。
def demo():
try:
yield "ready"
yield "go"
except ValueError:
yield "caught value error"
<p>g = demo()
print(next(g)) # "ready"
g.throw(ValueError) # 触发 except 分支
print(next(g)) # "caught value error"
-
throw()必须在生成器处于暂停态（即刚 yield 完、还没 next）时调用，否则报RuntimeError - 常用于测试生成器异常路径、实现协程间错误通知、或构建带恢复能力的状态机
- 如果生成器没对对应异常做
except，异常会继续向上冒泡到throw()调用方
for循环无法捕获生成器内yield异常的常见误区
很多人以为 for x in gen: 是“安全”的遍历方式，能自动跳过异常项——其实完全不是。只要生成器某次 yield 抛异常，for 就立刻停止，且异常不会被隐式捕获。
下面这段代码会直接崩溃，不会打印任何 "processed"：
def bad_gen():
yield 1 / 0 # 这里就崩了
yield 42
<p>for x in bad_gen(): # StopIteration 不会来，ZeroDivisionError 直接 raise
print("processed", x)
- 想在
for中容错，必须在外层包try/except，或改用while True+next()+except StopIteration - 不要依赖
for的“优雅退出”机制来掩盖生成器内部错误；它的职责只是消费，不是兜底 - 调试时注意区分：是生成器构造时报错（函数定义阶段无影响），还是第一次
next()时才触发（真正执行到 yield 才出问题）
生成器异常传播路径非常直接，没有隐藏代理或默认捕获逻辑。关键在于分清责任边界：谁触发 yield，谁负责处理它可能抛出的异常；而生成器自身是否要介入，取决于你是否需要控制恢复行为。最容易漏掉的是 throw() 这个接口，以及误信 for 循环有内置容错能力。
