Python捕获通用Exception为何是不良实践？如何兼顾日志与异常处理规范

为什么不推荐在业务逻辑中直接使用except Exception捕获所有异常 #

• 会掩盖代码本身的bug：比如代码中变量名拼写错误导致的NameError、调用不存在的方法导致的AttributeError等本应暴露的开发类错误，会被统一当作业务异常处理，你只会看到一条通用的错误日志，无法第一时间区分是业务输入问题还是代码逻辑错误，反而提升排查成本。
• 无法做针对性的异常处理：不同的异常对应不同的恢复逻辑，比如ZeroDivisionError可以提示用户修正除数，TypeError可以提示用户输入类型合规的参数，如果全部捕获统一处理，无法给用户明确的反馈，也无法执行对应的恢复逻辑，程序只能要么强制退出要么带着未知状态继续运行。

如何解决「未预期异常丢失日志」的问题 #

行业通用的最佳实践是分层捕获、各司其职，既不遗漏日志，也符合异常处理的规范：

1. 内层业务逻辑只捕获你能明确处理的具体异常，每类异常对应独立的处理逻辑，比如参数校验失败的提示、可重试错误的重试逻辑等。
2. 在程序的最顶层入口（比如你代码中的main函数最外层）增加一层全局兜底的except Exception，这层仅负责记录全量的错误日志（含完整调用栈）、执行必要的资源清理操作，之后主动优雅退出程序，不要让程序带着未知错误继续运行。

符合规范的代码示例 #

import jtp_aux as aux


def logger_path(path_logger):
    return aux.init_logger(path_logger)


def generic_function(a, b):
    return a/b


def main():
    logger = logger_path(r'log_scratch.log')
    # 顶层全局兜底，仅做日志记录和优雅退出
    try:
        # 业务逻辑区，捕获具体异常做针对性处理
        try:
            print(generic_function(2, 'l'))
        except ZeroDivisionError:
            logger.warning("除数不能为0，请修正后重试")
            # 此处可加对应处理逻辑，比如返回输入步骤
        except TypeError:
            logger.warning("运算参数仅支持数字类型，请检查输入")
            # 此处可加对应处理逻辑
    except Exception as e:
        # 所有未被内层捕获的异常统一在这里记录日志
        logger.error(f"未预期的程序错误: {e}", exc_info=True)
        # 清理资源后退出
        exit(1)


if __name__ == "__main__":
    main()

补充说明 #

并不是完全禁止使用except Exception，而是要明确它的使用场景：只有在程序最顶层做兜底日志记录的时候使用才是合理的，任何业务逻辑层面的异常捕获都应该明确指定异常类型，避免吞掉不该被忽略的错误。

内容的提问来源于stack exchange，提问作者banana_99