Python中__exit__返回True抑制的异常为何仍能被finally内sys.exc_info获取

先拆明白两个容易混的规则 #

很多人对上下文异常的认知存在两个默认误解，刚好凑成了这个现象的成因：

• 对__exit__返回True的作用理解不全：这个返回值的本质，只是告诉解释器别把这个异常继续往外抛了，拦截动作是发生在最内层CC类的作用域边界的。也就是说你在用户代码块里抛的ValueError，刚碰到CC的退出逻辑就被标记为“不需要继续传播”，根本没机会传到外层ctx函数的try块作用域里，自然不会触发对应的except分支。
• 对sys.exc_info()的读取逻辑理解有偏差：这个方法读的是当前线程存的异常上下文栈的快照，它不会判断“这个异常现在是不是还在往外传”，只看栈里有没有还没被弹出去的异常记录。

顺着contextlib.contextmanager的底层实现走一遍完整流程 #

生成器式上下文不是简单把yield前后的代码包装成__enter__和__exit__，它的内部流程和原生上下文有个很容易被忽略的差异，一步步走就懂了：

1. 进入流程：ctx生成器执行到with CC():，先跑CC的__enter__，然后遇到yield，控制权切出去，进到你写的用户代码块
2. 触发异常：用户代码块里抛出ValueError，这个异常首先沿着上下文的退出路径向内传，先触发最内层CC的__exit__逻辑
3. 异常被拦截：CC的__exit__收到这个异常后返回True，解释器收到信号，确定要抑制这个异常，停止向外传播
4. 流程退回ctx生成器：因为异常已经被内层拦下来了，生成器在yield的位置根本收不到需要处理的异常——这就是为什么except分支完全不触发的直接原因
5. 执行收尾逻辑：生成器顺着流程走到try块的最后，进入finally分支
   这里就是最关键的时序差：异常被标记为“不需要传播”的时候，并没有立刻从线程的异常栈里删掉。解释器要等整个上下文的退出流程完全走完，才会把栈里存的这个异常记录弹出去。
   你在finally里调用sys.exc_info()的时机，刚好比异常出栈的时机早一步，所以哪怕异常已经不往外传了，还是能从栈的快照里读到原始的异常信息。

为什么两个感知渠道会错位 #

说白了就是两套机制的触发节点没对齐：

• try...except的触发完全跟着异常的实际传播路径走：异常在CC的边界就被截停了，没走到外层try的监听范围，所以不会触发捕获
• sys.exc_info()的读取完全跟着线程异常栈的状态走：异常虽然被标记为不传播，但还赖在栈上没走，所以能被读到

补个容易踩的细节：如果不用contextlib装饰器，直接写两层嵌套的原生with语句，在内层__exit__返回True抑制异常的场景下，外层代码里调用sys.exc_info()是读不到异常的。正是因为装饰器在把异常传回生成器的流程里，会提前把异常绑定到当前线程的上下文，哪怕后续异常被内层拦截了，这个绑定关系在同步执行的代码块里也不会立刻解除，才造成了这种看起来矛盾的现象。

内容的提问来源于stack exchange，提问作者Hot.PxL