生成器关闭时如何处理GeneratorExit异常

Python生成器在被显式关闭（`gen.close()`）或隐式终止时会触发特殊的`GeneratorExit`异常，它继承自`BaseException`而非`Exception`，因此无法也不应被`try-except`捕获；正确的资源清理方式是将释放文件、连接、锁等操作统一置于`finally`块中——该块保证在任何退出路径下都会执行，但其中绝不可包含`yield`语句，否则将引发运行时错误；同时需注意，`close()`后生成器即进入不可恢复的`GEN_CLOSED`状态，后续调用`next()`或`send()`均会失败，而手动调用`close()`仅在提前中断迭代、持有长期资源或生成器未被上下文管理器自动包裹等场景下才真正必要，日常使用中更需警惕因忽略清理异常、误用`del`或混淆同步/异步关闭方式导致的资源泄漏与行为异常。

GeneratorExit不是普通异常，不能用try-except捕获

GeneratorExit 是 Python 生成器被显式关闭（gen.close()）或隐式结束（如 for 循环正常退出、垃圾回收）时由解释器抛出的特殊异常，它继承自 BaseException 而非 Exception。这意味着：

• except Exception: 或 except:（空 except）都捕获不到它
• 强行捕获 GeneratorExit 并吞掉它，会导致生成器无法真正关闭，可能引发 RuntimeError: generator ignored GeneratorExit
• 你**不应该**在生成器内部用 try...except GeneratorExit 去“处理”它

资源清理必须放在 finally 块中

生成器的正确清理姿势是：把释放文件句柄、关闭连接、解锁等逻辑统一放进 finally 子句。Python 保证只要生成器执行到 yield 后暂停过，无论因 close()、throw()、正常耗尽还是被 GC 回收，finally 都会执行。

示例：

def file_reader(path):
    f = open(path, 'r')
    try:
        for line in f:
            yield line.strip()
    finally:
        print(f"Closing {path}")  # 这里一定会执行
        f.close()  # 即使调用 gen.close() 也会走到这里

注意：finally 中不要有 yield，否则会触发 RuntimeError: generator raised StopIteration（Python 3.7+）或更早版本的未定义行为。

close() 调用后不能再 yield，也不能再调用 next()

一旦外部调用 gen.close()，生成器状态立即变为 GEN_CLOSED，后续任何操作都会失败：

• 再次调用 gen.close() → 无反应（安全，可重复调用）
• 调用 next(gen) 或 gen.send(...) → 抛出 StopIteration（Python 3.7+）或 RuntimeError: generator already executing（旧版）
• 在 finally 里 yield → 直接报错，如上所述

需要手动 close 的典型场景和陷阱

大多数时候你不需要显式调用 close() —— for 循环、list(gen)、sum(gen) 等都会自动调用。但以下情况必须主动 close：

• 生成器持有长期资源（如数据库连接、socket、子进程），且你提前中断迭代（比如 break 出 for 循环）
• 生成器作为上下文管理器的一部分，但没用 with 包裹
• 生成器被多处引用，你无法确定谁会最后消费它

• 在 except 块里忘了 gen.close()，导致资源泄漏
• 误以为 del gen 就等于关闭 —— 实际上只是减少引用计数，GC 时间不确定
• 在异步生成器（async def + yield）中混用同步 close() —— 应该用 agen.aclose()

最易被忽略的一点：finally 块里的代码可能抛出新异常，这会掩盖原本的 GeneratorExit；如果清理逻辑本身不可靠（比如网络超时、磁盘满），最好加一层 try/except 包住清理语句，避免中断关闭流程。

今天关于《生成器关闭时如何处理GeneratorExit异常》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！