Python的logging handler抛出异常时其余handler的执行逻辑是怎样的？

核心结论 #

基于Python标准库logging模块的默认实现，你提出的第一种推测完全成立：

• 各handler的执行流程是独立隔离的，单个handler抛出的常规异常，不会阻断其他handler的执行流程，也不会造成handler静默失效。
• 对应你提到的典型场景：即便配置的SMTPHandler因网络断开抛出连接异常，同配置下的RotatingFileHandler仍会被正常触发，完成日志文件写入、轮转的全流程。

标准库的实际执行逻辑 #

当一条日志事件触发时，Logger会通过内置的callHandlers方法遍历所有挂载的日志处理器：

遍历过程中，每一个handler的调用都会被单独包裹一层异常捕获逻辑。如果某一个handler在执行emit、flush等核心方法时抛出常规Exception，库会自动调用内置的handleError逻辑打印错误提示（默认输出到stderr），完全不会打断对剩余handler的遍历流程。

对三种推测的逐一排除 #

• 关于“RotatingFileHandler会按配置顺序随机失效”的推测：不存在随机失效的设计逻辑，handler的遍历严格按照注册顺序执行，单handler的异常仅影响自身的执行结果，不会干扰前后其他handler的正常运行。
• 关于“只要任意一个handler执行失败，其余所有handler都无法正常执行”的推测：该情况仅在自定义修改了callHandlers遍历逻辑、移除了单handler异常捕获的特殊场景下才会出现，不属于标准logging库的默认行为。

特殊边界说明 #

标准库的异常捕获仅覆盖常规Exception类别的异常。如果某一个handler抛出的是继承自BaseException的特殊异常（比如手动触发的SystemExit、KeyboardInterrupt、致命的内存溢出错误），才有可能中断整体执行流程，这类情况不属于日常业务场景下的普通异常范畴。

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