ExceptionTable 的引入与“零成本”异常处理
在 python 3.11 版本之前，异常处理主要依赖于一个运行时维护的“块栈”（block stack）。当进入 try 块时，会通过 setup_finally 等指令将异常处理信息压入栈中；当离开 try 块时，再通过 pop_block 等指令弹出。这种机制的缺点在于，即使没有异常发生，程序也需要执行额外的指令来管理这个块栈，增加了不必要的开销。
为了解决这一问题，Python 3.11 引入了“零成本”（zero-cost）异常处理机制，其核心就是 ExceptionTable。所谓“零成本”，是指在代码正常执行、没有异常抛出的情况下，异常处理的开销被降至最低（接近于零）。这意味着，大部分时间里，你的程序不会因为潜在的异常处理逻辑而变慢。当然，代价是当异常真正发生时，处理异常的成本会略微增加，但这种权衡在实际应用中通常是划算的，因为异常的发生频率远低于正常执行的频率。
ExceptionTable 的工作原理是，它不再在运行时动态管理块栈，而是预先编译生成一张静态的表。这张表记录了字节码指令的起始范围、结束范围以及对应的异常处理目标地址。当某个指令引发异常时，解释器会根据该指令的偏移量在 ExceptionTable 中查找匹配的条目，并直接跳转到指定的异常处理目标地址执行。
让我们通过一个简单的例子来对比 Python 3.10 和 Python 3.11+ 在异常处理字节码上的差异：
Python 3.10 的字节码示例：
立即学习“Python免费学习笔记（深入）”；
def f():
try:
g(0)
except:
return "fail"在 Python 3.10 中，dis.dis(f) 的输出会包含 SETUP_FINALLY 和 POP_BLOCK 等指令：
2 0 SETUP_FINALLY 7 (to 16) # 压入异常处理块
3 2 LOAD_GLOBAL 0 (g)
4 LOAD_CONST 1 (0)
6 CALL_NO_KW 1
8 POP_TOP
10 POP_BLOCK # 弹出异常处理块
12 LOAD_CONST 0 (None)
14 RETURN_VALUE
4 >> 16 POP_TOP
18 POP_TOP
20 POP_TOP
5 22 POP_EXCEPT
24 LOAD_CONST 3 ('fail')
26 RETURN_VALUE可以看到，即使 g(0) 没有引发异常，SETUP_FINALLY 和 POP_BLOCK 也会被执行。
Python 3.11+ 的字节码示例：
同样的 f 函数在 Python 3.11+ 中编译后的字节码则大为不同：
1 0 RESUME 0
2 2 NOP
3 4 LOAD_GLOBAL 1 (g + NULL)
16 LOAD_CONST 1 (0)
18 PRECALL 1
22 CALL 1
32 POP_TOP
34 LOAD_CONST 0 (None)
36 RETURN_VALUE
>> 38 PUSH_EXC_INFO
4 40 POP_TOP
5 42 POP_EXCEPT
44 LOAD_CONST 2 ('fail')
46 RETURN_VALUE
>> 48 COPY 3
50 POP_EXCEPT
52 RERAISE 1
ExceptionTable:
4 to 32 -> 38 [0]
38 to 40 -> 48 [1] lasti在 Python 3.11+ 的输出中，我们不再看到 SETUP_FINALLY 和 POP_BLOCK 等指令。取而代之的是末尾的 ExceptionTable。例如，CALL 指令的偏移量是 22，它落在 ExceptionTable 的第一条目 4 to 32 的范围内。这意味着如果 CALL 指令引发异常，控制流将直接跳转到偏移量 38 处，即 PUSH_EXC_INFO 指令所在的位置，从而开始异常处理流程。
访问与解析 ExceptionTable
ExceptionTable 实际上是存储在代码对象（code object）中的一个属性：co_exceptiontable。这是一个字节串（bytes），包含了编码后的异常表信息。
我们可以通过以下方式访问它：
def foo():
c = 1 + 2
return c
print(foo.__code__.co_exceptiontable)
# 输出: b'' (没有异常处理，所以为空)
def foo_with_exception():
try:
1/0
except:
pass
print(foo_with_exception.__code__.co_exceptiontable)
# 输出: b'\x82\x05\x08\x00\x88\x02\x0c\x03' (包含异常处理信息)直接查看 co_exceptiontable 的字节串并不直观。Python 的 dis 模块内部提供了解析这个字节串的工具函数 _parse_exception_table，它可以将字节串解析成更易读的 _ExceptionTableEntry 对象列表。
from dis import _parse_exception_table
def foo_with_exception():
try:
1/0
except:
pass
# 解析异常表
parsed_table = _parse_exception_table(foo_with_exception.__code__)
for entry in parsed_table:
print(entry)
# 输出示例：
# _ExceptionTableEntry(start=4, end=14, target=16, depth=0, lasti=False)
# _ExceptionTableEntry(start=16, end=20, target=24, depth=1, lasti=True)每个 _ExceptionTableEntry 对象包含以下关键属性：
- start: 异常处理块的起始字节码偏移量（包含）。
- end: 异常处理块的结束字节码偏移量（不包含）。
- target: 发生异常时应跳转到的字节码偏移量。
- depth: 异常处理的嵌套深度（用于处理多个 except 或 finally 块）。
- lasti: 布尔值，表示是否是最后一个指令。
ExceptionTable 的工作机制
当 Python 解释器执行字节码时，如果某个指令引发了异常，解释器会立即停止当前指令的执行，并根据该指令的字节码偏移量，在当前函数的 ExceptionTable 中查找匹配的条目。
查找过程如下：
- 遍历 ExceptionTable 中的所有 _ExceptionTableEntry。
- 对于每个条目，检查引发异常的指令的偏移量是否落在 start 和 end 之间（即 start
- 如果找到匹配的条目，解释器会将控制流跳转到该条目指定的 target 偏移量处继续执行，通常是进入异常处理代码块（如 except 或 finally）。
这种机制的优势在于，它将异常处理的逻辑与正常执行流分离。在没有异常的情况下，解释器无需执行任何与异常处理相关的额外指令，从而提高了执行效率。只有当异常真正发生时，才会付出查找和跳转的成本。
总结与注意事项
ExceptionTable 是 Python 3.11+ 解释器在性能优化方面的一项重要改进。它通过引入“零成本”异常处理机制，显著提升了正常程序执行的效率。
主要优点：
- 性能提升： 在没有异常抛出的常见情况下，移除了块栈管理的运行时开销。
- 代码清晰： 字节码层面不再需要显式的 SETUP_FINALLY 或 POP_BLOCK 指令，使得字节码本身更专注于业务逻辑。
注意事项：
- ExceptionTable 是解释器内部的实现细节，通常开发者无需直接与之交互。dis 模块的输出是为了帮助理解 Python 内部机制。
- 虽然 _parse_exception_table 函数可以用于解析 co_exceptiontable，但这是一个私有函数（以 _ 开头），其接口在未来的 Python 版本中可能会发生变化，不建议在生产代码中直接依赖。
- 理解 ExceptionTable 有助于深入了解 Python 运行时的工作方式，特别是在进行性能分析和优化时，能够更好地理解字节码的行为。
通过 ExceptionTable，Python 在保持其易用性和强大功能的同时，在底层执行效率上迈出了重要一步。
