finally 中的 return 会静默丢弃正在传播的异常，直接返回其值；Python 允许该行为，而 Java 编译器会报错；根本原因是函数退出分两步，finally 的 return 接管整个退出流程，覆盖暂存异常。
finally 中的 return 会吞掉正在传播的异常
Python 的 finally 块只要包含 return，无论 try 或 except 中是否 raise 了异常，该异常都会被静默丢弃，函数直接返回 finally 中的值。这不是“异常被处理了”，而是控制流被强行劫持。
- try 中
raise ValueError("boom")→ 程序本该向上抛出异常 - 但
finally里有return "done"→ 异常被抹除，调用方收到字符串"done"，且无任何警告 - 这种行为与 Java 完全不同：Java 编译器会直接报错
unreachable statement，而 Python 允许运行，却悄悄改写逻辑
为什么 return 在 finally 里能覆盖异常？
根本原因在于 Python 的返回机制：函数的“退出动作”（包括抛异常）不是原子操作，而是分两步——先求值暂存，再跳转执行 finally。一旦 finally 中出现 return，它就接管整个退出流程。
-
try中的raise会被暂存为“待传播异常” - 然后强制跳入
finally执行 -
finally中的return触发函数立即返回，原暂存的异常被丢弃 - 如果
finally中还抛出新异常（比如raise RuntimeError()），则它会完全取代旧异常
常见误用：文件操作 + finally return
想确保文件关闭、又想返回结果，很容易把两者都塞进 finally：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
def read_config():
f = None
try:
f = open("config.json")
return json.load(f) # 正常路径返回数据
except FileNotFoundError:
return {"default": True} # 错误路径返回默认值
finally:
if f:
f.close()
return "closed" # ← 这一行让上面所有 return 都失效- 即使
json.load(f)成功，函数也只返回字符串"closed" - 即使
FileNotFoundError被捕获，也不会走 except 分支的return，而是被finally的return覆盖 - 更隐蔽的是：如果
f.close()自身失败（如磁盘只读），还会引发新异常，进一步掩盖原始问题
真正安全的替代写法
资源清理和返回值决策必须解耦。finally 只做一件事：清理；返回逻辑统一收口到函数末尾。
立即学习“Python免费学习笔记（深入）”；
- 用局部变量保存结果：
result = None，在try和except中赋值 -
finally只负责f.close()、lock.release()这类无副作用操作 - 所有
return都挪到函数最后，避免分散在多个分支中 - 配合静态检查工具（如
pylint的W0717规则）可自动拦截finally中的return
真正容易被忽略的点是：这个覆盖行为不报错、不告警、不打断调试器单步——它只是安静地让你的函数每次返回同一个“假成功”值，直到某个边界 case 暴露逻辑断裂。
