Python异常体系深度解析与工程实践指南

很多开发者写Python时对异常的理解停留在try...except Exception这一层，结果线上出现问题时，日志里只剩一句被except: pass吞掉的错误，排查起来非常痛苦。更隐蔽的问题在于：有些人用except Exception包裹一切，却在进程收到终止信号时毫无反应；有些人写了自定义异常，却继承错了基类，导致框架层根本不识别。

Python的异常并不是一堆零散的类名，而是一棵有严格继承关系的类树。理解这棵树，你才能回答下面这些问题：

• 为什么except Exception抓不到KeyboardInterrupt？
• KeyError和IndexError都是LookupError的子类，能不能一次捕获？
• 自定义异常应该继承Exception还是BaseException？
• raise ... from ...到底改变了什么？
• finally和return同时出现时谁先执行？

本文先给出完整的继承体系图，再逐层剖析每个分支的语义、典型场景与最佳实践，最后给出自定义异常的设计范式与线上排障建议。

一、异常继承树全景

Python 3中所有异常都继承自BaseException，它位于继承树的最顶端。整体结构可以概括为「两大分支 + 若干直系子类」：

flowchart TD
    BE["BaseException"] --> SE["SystemExit"]
    BE --> KI["KeyboardInterrupt"]
    BE --> GE["GeneratorExit"]
    BE --> EX["Exception"]
    EX --> AE["ArithmeticError"]
    EX --> LE["LookupError"]
    EX --> VE["ValueError"]
    EX --> TE["TypeError"]
    EX --> NE["NameError"]
    EX --> ATE["AttributeError"]
    EX --> OE["OSError"]
    EX --> RE["RuntimeError"]
    EX --> IE["ImportError"]
    EX --> UE["UnicodeError"]
    EX --> ASE["AssertionError"]
    EX --> SIE["StopIteration"]
    AE --> ZDE["ZeroDivisionError"]
    AE --> OVE["OverflowError"]
    AE --> FPE["FloatingPointError"]
    LE --> KE["KeyError"]
    LE --> IXE["IndexError"]
    NE --> ULE["UnboundLocalError"]
    OE --> FNFE["FileNotFoundError"]
    OE --> PEE["PermissionError"]
    OE --> TOTE["TimeoutError"]
    OE --> CPE["ConnectionError"]
    RE --> RCE["RecursionError"]
    RE --> NIE["NotImplementedError"]
    IE --> MNFE["ModuleNotFoundError"]
    UE --> UEE["UnicodeEncodeError"]
    UE --> UDE["UnicodeDecodeError"]

用文字描述关键分层：

层级	类	语义	是否应被业务except捕获
根	BaseException	所有异常的基类	否
直系	SystemExit	sys.exit()抛出，解释器退出	否
直系	KeyboardInterrupt	用户按下Ctrl+C	否
直系	GeneratorExit	生成器/协程被关闭	否
主体	Exception	所有常规业务异常	是
子分支	ArithmeticError	算术类错误	视情况
子分支	LookupError	查找类错误	视情况
子分支	OSError	操作系统/IO类错误	视情况
子分支	RuntimeError	运行时逻辑错误	视情况

理解这张表的关键在于：BaseException的直系子类代表的是“解释器级控制流”，而非“程序错误”。SystemExit、KeyboardInterrupt、GeneratorExit三者都不表示代码写错了，而是表示“程序需要退出/被打断/生成器需要清理”。因此用except Exception把它们排除在外，恰恰是Python设计者的有意安排——避免业务层的兜底捕获把退出信号也一并吞掉。

二、第一分支：Exception之外的三个“控制流异常”

2.1 SystemExit：优雅退出的信号

sys.exit()抛出的就是SystemExit。它携带一个退出码，解释器在捕获后会终止进程。很多脚本框架会在main()外层写except Exception做兜底日志，这时SystemExit不会被捕获，进程仍能按预期退出。若误写成except BaseException，则退出信号被吞，脚本可能“卡死”在异常处理逻辑里。

import sys
def main():
    try:
        sys.exit(2)
    except Exception:
        print("不会执行到这里")
    # SystemExit继续向上传播，进程以退出码2结束
main()

2.2 KeyboardInterrupt：用户意图的边界

KeyboardInterrupt对应SIGINT。它之所以不继承Exception，是为了让“清理逻辑”和“业务兜底逻辑”分离：清理逻辑通常写在finally中，无论是否被中断都会执行；而业务兜底的except Exception不应把用户中断当成业务错误处理。

2.3 GeneratorExit：生成器的收尾信号

当生成器被close()或垃圾回收时，会向生成器内部抛出GeneratorExit。生成器内部若捕获它并继续yield，会触发RuntimeError。这个异常几乎不会出现在业务代码的except中，但写生成器清理逻辑时需要知道它的存在。

三、第二分支：Exception家族的分层语义

3.1 算术分支：ArithmeticError

ZeroDivisionError、OverflowError、FloatingPointError共同继承ArithmeticError。实践中ZeroDivisionError最常见，通常在入口做参数校验比异常捕获更划算；OverflowError在Python的大整数场景较少出现，但在与底层数值库交互时需要留意。

3.2 查找分支：LookupError

KeyError与IndexError都继承LookupError，意味着可以一次性捕获“键不存在”和“下标越界”：

try:
    value = data[key] if isinstance(data, dict) else data[index]
except LookupError:
    value = default

但更推荐的做法是分别捕获KeyError和IndexError，因为两者的修复策略不同：前者往往意味着数据结构与预期不符，后者往往意味着边界计算有误。统一捕获会掩盖问题定位线索。

3.3 名称与属性分支

NameError及其子类UnboundLocalError表示“名字未定义”，后者常见于函数内先引用后赋值导致的局部变量未绑定。AttributeError表示对象上没有该属性。这两类异常通常属于编码错误，不应被业务层随意吞掉，而应让它们暴露出来。

3.4 操作系统分支：OSError

OSError是现代Python中文件与网络IO错误的统称，FileNotFoundError、PermissionError、TimeoutError、ConnectionError都是它的子类。这条分支是最需要精细化捕获的区域：文件不存在可以降级处理，权限错误通常需要告警，超时错误可能需要重试。把三者混在一个except OSError里，会让重试策略失去针对性。

3.5 运行时分支：RuntimeError

RecursionError表示递归过深，NotImplementedError表示抽象方法未实现。后者在框架设计中非常有用：基类定义接口时raise NotImplementedError，强制子类实现。

3.6 导入与编码分支

ModuleNotFoundError继承ImportError，用于区分“模块不存在”与“模块存在但内部导入失败”。UnicodeEncodeError与UnicodeDecodeError继承UnicodeError，在跨编码处理文本时是高频问题，捕获时应记录原始字节与编码名，便于复现。

四、raise … from …：异常链的真正含义

raise NewError from old_error做两件事：一是把old_error设置为NewError的__cause__，二是在打印traceback时显示“The above exception was the direct cause of…”。与之相对，raise NewError在异常处理块内会自动把当前异常设为__context__，显示“During handling of the above exception…”。

两者的区别在于语义：from表示“因果关系”，适合把底层异常翻译成领域异常；隐式context表示“处理过程中又出错”，适合保留现场。排障时若只看到外层异常而丢失原因，往往是因为用了raise NewError()却没有from。

class StorageError(Exception):
    pass
def load_config(path):
    try:
        with open(path) as f:
            return f.read()
    except FileNotFoundError as exc:
        raise StorageError(f"配置文件缺失: {path}") from exc

这样上层捕获StorageError时，traceback里仍能看到FileNotFoundError的原始堆栈。

五、finally与return的执行顺序

finally块在return表达式求值之后、函数真正返回之前执行。也就是说：

def f():
    try:
        return "try"
    finally:
        print("finally")
print(f())  # 先打印finally，再打印try

若finally中也有return，它会覆盖try中的返回值；若finally中抛出异常，它会覆盖try中的return。因此在finally中写return或raise是高风险写法，应严格避免。finally的正确用途是释放资源、关闭连接、记录收尾日志。

六、自定义异常的设计范式

1. 继承Exception，不要继承BaseException：后者会绕过常规捕获逻辑，破坏框架的兜底机制。
2. 建立领域异常基类：如AppError(Exception)，所有业务异常继承它，便于上层统一捕获与转换。
3. 携带结构化上下文：异常对象上挂载错误码、请求ID、关键参数，而不是把信息全塞进字符串。
4. 区分“可重试”与“不可重试”：用不同子类表达，重试中间件据此决策。
5. 不要用异常做常规控制流：能用返回值表达的分支不要抛异常，异常应留给“意外情况”。

class AppError(Exception):
    code = "APP_ERROR"
    retryable = False
    def __init__(self, message, **context):
        super().__init__(message)
        self.context = context
class UpstreamTimeout(AppError):
    code = "UPSTREAM_TIMEOUT"
    retryable = True

七、线上排障的落地建议

• 禁止裸except:与except: pass，至少记录logger.exception(...)保留堆栈。
• 兜底捕获用except Exception，绝不用except BaseException，除非在进程最外层做退出清理。
• 按异常子类精细化捕获，把“可恢复”与“不可恢复”分开处理。
• 记录异常时同时记录__cause__链，避免只打外层消息。
• 对超时、连接类异常设计明确的重试与退避策略，而不是统一重试。

异常体系不是语法糖，而是Python把“错误分类学”编码进类型系统的结果。把继承树读懂，把捕获粒度设计对，线上日志才会从“一句被吞掉的信息”变成可定位、可归因、可恢复的工程资产。