except* 必须单独出现在 try 块末尾,不能与普通 except 混用;Python 3.11 引入它专用于匹配异常组中的子异常,语义和控制流与传统 except 不兼容,需通过嵌套 try 实现单异常与异常组的分层处理。
Python 3.11 引入的 except* 是为异常组(ExceptionGroup)设计的专用语法,它和传统 except 在语义和控制流上不兼容。你不能在同一个 try 块里把 except ValueError: 和 except* RuntimeError: 并列书写——这会直接触发 SyntaxError: cannot mix 'except' and 'except*' in the same try statement。
根本原因在于:普通 except 匹配单个异常,而 except* 匹配异常组中「所有匹配子异常」并返回新异常组;两者对异常栈展开、传播逻辑完全不同,CPython 解析器强制隔离。
常见需求是:主逻辑可能抛出单个异常(如 ValueError),也可能由 asyncio.gather(..., return_exceptions=True) 或 exceptiongroup.ExceptionGroup 构造出异常组。这时需分层捕获:
try 用 except* 处理可能的异常组except)用传统 except 捕获单个异常 —— 但必须确保它不与 except* 同级正确写法示例:
try:
try:
# 可能抛出单个异常,也可能抛出 ExceptionGroup
risky_operation()
except ValueError as e:
print(f"单个 ValueError: {e}")
raise # 或处理后继续抛出
except* Ke
yError as eg:
print(f"捕获到 {len(eg.exceptions)} 个 KeyError")
except* TypeError as eg:
print(f"捕获到 {len(eg.exceptions)} 个 TypeError")
注意:内层 except ValueError 先于外层 except* 执行;如果内层没捕获,异常才会透出到外层被 except* 处理(前提是它是 ExceptionGroup)。
except* 不是“捕获一次”,而是对异常组中每个子异常独立尝试匹配。匹配成功的子异常会被提取出来,组成新的 ExceptionGroup 绑定到变量(如 eg),未匹配的子异常继续向上抛出。
except* KeyError 子句可能绑定到含 0、1 或多个 KeyError 的新组,len(eg.exceptions) 就是实际匹配数except* 子句按顺序尝试,但**不短路**:即使第一个 except* KeyError 匹配了部分子异常,第二个 except* ValueError 仍会对剩余未匹配子异常尝试匹配except* 都没匹配到任何子异常,原始异常组原样抛出错误认知:“写个 except* Exception 就像兜底的 except Exception”——实际它只匹配组内是 Exception 实例的子异常,且不会抑制其他未匹配子异常。
很多用户以为只要用了 asyncio.gather() 就自动产生异常组,其实不然。默认情况下,gather() 遇到首个异常就立刻中断并抛出那个异常(单个)。必须显式传入 return_exceptions=True,失败任务才以 Exception 实例形式进入结果列表,之后手动构造或由框架生成 ExceptionGroup。
asyncio.gather(a(), b(), return_exceptions=True) → 结果是 [res_a, res_b],其中失败项是 Exception 实例except*,需进一步用 exceptiongroup.ExceptionGroup("task failed", exceptions) 包装,或依赖支持异常组的库(如 Python 3.12+ 的 asyncio.TaskGroup)trio.lowlevel.spawn_system_task() 或 trio.open_nursery() 在多任务失败时天然产生 ExceptionGroup,可直接被 except* 捕获漏掉 return_exceptions=True 或没用 ExceptionGroup 包装,except* 就永远不会执行——这点在调试时最容易卡住。