Python except as 的名称清理：异常处理结束，为什么原来同名的变量也不见了
脚本先给 error 赋了一个默认说明，随后又写 except ValueError as error。异常在处理块里打印正常，离开后再次访问却抛出 UnboundLocalError。这里不是异常还没被捕获，而是处理结束时，同名绑定被清理了，之前的值也不会自动恢复。
下面让同一个函数分别走正常路径与异常路径，保留相同的初始赋值。只制造内存中的 ValueError，不读取文件。保存为 demo.py，运行 python demo.py。summary 是专门用于带出处理结果的另一个名称。
AI模型生成概念示意：处理区域里的临时错误标签在出口被移除，需要保留的简短摘要另行放入托盘；不是调试器截图。
def probe(should_fail):
error = "earlier value"
summary = "no error"
try:
if should_fail:
raise ValueError("demo")
except ValueError as error:
summary = type(error).__name__ + ": " + str(error)
print("inside:", summary)
present = "error" in locals()
print("binding present:", present)
try:
remaining = error
except UnboundLocalError:
remaining = "<cleared>"
return summary, remaining
normal = probe(False)
failed = probe(True)
assert normal == ("no error", "earlier value")
assert failed == ("ValueError: demo", "<cleared>")
print("normal:", normal)
print("failed:", failed)先看处理块是否真的执行
正常调用先打印 binding present: True，因为没有异常，except 分支没有执行，error 仍保存 earlier value。异常调用先打印 inside: ValueError: demo，再打印 binding present: False。两次调用的差别不是函数返回时间，而是目标名称是否经历了 except 绑定与退出清理。
最终 normal 是 ('no error', 'earlier value')，failed 是 ('ValueError: demo', '<cleared>')。第二项来自对真实读取异常的捕获，并非只凭 locals 的展示推断。函数作用域内读取已无绑定的局部名称，会触发 UnboundLocalError；不要把具体异常类型与模块顶层的名称查找混在一起。
这个清理规则专门针对异常目标
语言参考把该行为解释为处理块结束时删除 as 后面的名称。因此，异常出现前已经存在一个同名值，也不会在清理后“弹回来”。默认文案、业务状态和异常目标最好使用不同名字，让各自的生命周期在代码里一眼可见。
它也不能推广成“Python离开任何缩进块都会删除变量”。普通 if、for 与 with 的名称绑定各有规则。本例中 summary 在 except 内被更新，块外仍能读取，正好说明清理针对的是异常目标 error，而不是把整个处理块内的变量全部丢掉。
需要带出去的内容应明确保存
示例在处理块内提取类型名与消息，存进预先初始化的 summary。初始化让没有异常的路径也有明确结果，调用者可以同时处理成功和失败。真实业务可返回结构化状态对象，并只保留后续判断真正需要的字段。
如果确实需要异常对象，也可以用另一个名称显式保存；不过对象会携带回溯等诊断信息，保存时间应符合排查用途。这里选择摘要，是为了演示名称清理与结果传递，不是在实现通用异常日志框架，也不保证任意错误消息适合直接展示给用户。
回归测试至少覆盖无异常、预期异常和处理块自身失败。不要把“块外名称消失”的报错笼统吞掉后继续当作成功，更不要依赖此前同名变量的默认值兜底。把输出状态单独初始化并在处理处赋值，通常比跨越边界持有临时捕获名称更容易检查。
资料核对日期：2026年10月2日。示例在本地 Python 3.12.14 实际执行，全部断言通过；输出对应文中固定输入。
