Python 3.11 ExceptionGroup 异常捕获方法

Python 3.11 引入的 ExceptionGroup 彻底改变了多异常处理范式——当并发任务（如 asyncio.TaskGroup）同时抛出多种异常时，传统 except 语句完全失效，因为它只能捕获外层的 ExceptionGroup 对象本身，而无法解包和分流内部子异常；唯有专为此设计的 except* 语法才能真正实现“精准匹配、按需分流、未匹配者继续传播”的智能异常处理，它支持多块级联匹配、保留未处理子异常向上冒泡，并成为协程错误处理中不可或缺的核心机制——忽略它，你的异常捕获逻辑注定失效；掌握它，才能写出健壮、可维护的现代 Python 并发代码。

用 except* 捕获 ExceptionGroup 是唯一正确方式

Python 3.11 引入 ExceptionGroup 后，传统 except 无法解包多个异常——它只匹配最外层的 ExceptionGroup 实例本身，不会自动遍历子异常。必须用新语法 except* 才能真正“捕获并分流”其中的各类异常。

常见错误是写成这样：

try:
    raise ExceptionGroup("eg", [ValueError("bad"), TypeError("nope")])
except ValueError:  # ❌ 不会进入这里
    print("got value error")
except TypeError:   # ❌ 也不会进入这里
    print("got type error")

实际只会触发 Uncaught ExceptionGroup，因为 ExceptionGroup 不是 ValueError 的子类（它是平行结构）。

• except* 是专为 ExceptionGroup 设计的语法，支持同时匹配多个子异常
• 一个 except* 块可匹配零个、一个或多个子异常，不中断其余未匹配的异常传播
• 可以写多个 except* 块，按顺序尝试匹配剩余未处理的子异常

except* 的匹配行为和嵌套传播规则

except* 不是“全有或全无”，而是“尽力匹配”：对 ExceptionGroup 中每个子异常单独尝试匹配，匹配成功的被该块处理，失败的继续留在组内，供后续 except* 块处理，或最终冒泡为未捕获异常。

示例：

try:
    raise ExceptionGroup("ops", [
        ValueError("bad input"),
        OSError(2, "No such file"),
        RuntimeError("uh oh")
    ])
except* ValueError as eg:
    print(f"ValueErrors: {len(eg.exceptions)}")
except* OSError as eg:
    print(f"OSError: {eg.exceptions[0]}")
except* Exception as eg:
    print(f"others: {eg.exceptions}")

输出：

ValueErrors: 1
OSError: [Errno 2] No such file
others: [RuntimeError('uh oh')]

• 每个 except* 接收的是一个新 ExceptionGroup，只含本次匹配到的子异常（eg.exceptions 是列表）
• 未被任何 except* 匹配的子异常，会保留在原组中继续向上抛出
• 如果所有子异常都未被匹配，整个 ExceptionGroup 仍会冒泡，不会静默丢弃

与 except 混用时的优先级和陷阱

except 和 except* 可共存，但顺序和意图容易混淆。关键点：普通 except 先于 except* 运行，且它只看到最外层的 ExceptionGroup 对象本身。

例如：

try:
    raise ExceptionGroup("eg", [KeyError("x"), ZeroDivisionError()])
except ExceptionGroup:  # ✅ 能捕获，但你拿到的是整个组，不是子异常
    print("caught the group itself")
except* KeyError:       # ❌ 永远不会执行，因为上面已捕获
    pass

反过来说，如果想先处理特定子异常，再兜底处理整个组，必须把 except* 放在前面：

• 把 except* 块写在 except 块之前，否则后者会提前截断
• 避免用 except BaseException: 或 except Exception: 在 except* 之前——它会吞掉整个组
• 若真需要兜底捕获未被 except* 处理的剩余异常，可用 except* Exception:，它只匹配剩下的子异常，不干扰已有逻辑

实际协程/TaskGroup 场景下的典型用法

asyncio.TaskGroup（Python 3.11+）在多个任务出错时会自动抛出 ExceptionGroup，这是最常遇到该异常的地方。此时不能靠单个 except 安全处理。

正确写法：

import asyncio
<p>async def main():
try:
async with asyncio.TaskGroup() as tg:
tg.create_task(asyncio.sleep(1))
tg.create_task(crash_soon())
except<em> ValueError as eg:
for e in eg.exceptions:
print("ValueError from task:", e)
except</em> RuntimeError as eg:
print("RuntimeError group size:", len(eg.exceptions))</p><p>async def crash_soon():
await asyncio.sleep(0.1)
raise ValueError("oops")</p>

注意：

• 不要试图在 TaskGroup 外层用 except ValueError: ——它不会命中
• 若任务中混发多种异常（如部分超时、部分解析失败），except* 是唯一能分类响应的方式
• ExceptionGroup 的 message（如 "unhandled errors"）只是提示，真正信息在 .exceptions 列表里

最容易被忽略的是：即使只预期一种异常类型，也得用 except*，而不是退化回 except 加手动遍历 __cause__ 或 args——那既不可靠也不符合语义。

本篇关于《Python 3.11 ExceptionGroup 异常捕获方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！