Python大型脚本用try/except实现异常时执行清理是否为正确写法

你搜到的try/except SystemExit写法不是正确做法，存在两个核心问题：

• 捕获范围极窄：只能拦截sys.exit()触发的SystemExit异常，普通代码报错、KeyboardInterrupt（Ctrl+C终止程序）等场景下，你写的清理逻辑根本不会执行
• 可维护性极差：把全量业务逻辑塞进同一个大try块，后续迭代时很容易混淆异常捕获边界，本该单独处理的业务异常会被外层块吞掉，排查问题的成本非常高。

针对你要实现「无论程序是否抛错都执行清理」的需求，有三个成熟的标准实现方案，按适用场景选就行：

方案1：try/finally 结构（最通用、最推荐的基础写法） #

Python的finally块天生就符合你的需求：无论try块内是正常执行完成、抛出任意类型异常、还是调用sys.exit()触发退出，finally块内的代码一定会被执行，不需要单独捕获异常再重抛。
你完全不需要把所有业务代码都塞在try块里，只要把程序入口的主函数调用放在try块中即可：

# 所有业务函数定义、导入都正常写在外面，不用缩进进try块
from other_module import func1, func2, cleanup

def main():
    # 这里写你的业务逻辑，随便调用其他模块的函数
    res = func1()
    func2(res)

if __name__ == "__main__":
    try:
        main()
    finally:
        # 所有清理逻辑统一放在这里
        cleanup()

注意：如果是操作系统强杀进程（比如kill -9、主机断电、手动调用os._exit()），任何清理逻辑都无法执行，这是操作系统层面的限制，所有编程语言都存在这个情况，不需要额外处理。

方案2：上下文管理器托管资源（适合有明确资源生命周期的场景） #

如果你的清理逻辑是对应特定资源的（比如关闭数据库连接、释放文件锁、删除临时文件），可以用上下文管理器把资源的初始化、清理逻辑封装起来，通过with语句托管，退出with块时会自动执行清理，哪怕块内抛错也不受影响：

from contextlib import contextmanager

@contextmanager
def managed_runtime():
    # 资源初始化逻辑
    db_conn = connect_db()
    file_lock = acquire_lock()
    try:
        # 把初始化好的资源传给业务逻辑
        yield {"db": db_conn, "lock": file_lock}
    finally:
        # 对应资源的清理逻辑，退出with块必定执行
        file_lock.release()
        db_conn.close()

if __name__ == "__main__":
    with managed_runtime() as ctx:
        # 业务逻辑写在with块内，不用手动写清理调用
        run_biz_logic(ctx["db"])

方案3：atexit 注册全局退出回调（适合全局级清理场景） #

如果你的清理逻辑是全局生效的，不想在代码结构上做缩进调整，可以用Python标准库atexit注册退出时执行的回调函数，程序正常退出、异常退出、sys.exit()触发退出时都会执行注册的清理函数：

import atexit
from other_module import func1, func2, cleanup

# 提前注册清理函数
atexit.register(cleanup)

# 所有业务逻辑正常平铺写，不需要套try块
if __name__ == "__main__":
    res = func1()
    func2(res)

这个方案的注意点和try/finally一致：强杀进程、os._exit()的场景下回调不会触发。

你搜到的示例代码只覆盖了SystemExit这一种非常窄的退出场景，完全达不到「出错也执行清理」的要求，不要照着用。

内容的提问来源于stack exchange，提问作者Manolo Dominguez Becerra