已取消的Task随等待方式不同抛出不同异常的原因是什么？

基础规则铺垫 #

首先明确两个.NET Task底层的核心规则：

• Task状态判定规则：Task进入Canceled状态而非Faulted状态的核心判定条件为：委托内抛出的OperationCanceledException携带的CancellationToken，与创建Task时显式传入调度器的CancellationToken匹配。部分.NET版本会放宽规则：若异常携带的Token本身已处于取消状态，即使未传入调度器也会判定为Canceled。
• 等待逻辑的异常处理差异：
  • 调用Wait()同步等待时，会直接读取Task.Exception属性，该属性固定返回AggregateException，且对于标记为Canceled状态的Task，框架会自动将原始取消异常包装为TaskCanceledException作为内层异常。
  • 使用await异步等待时，不会走Task.Exception的包装逻辑，会直接提取Task存储的原始取消异常抛出。

各场景差异详解 #

场景1：手动抛出OperationCanceledException #

代码中手动构造的OperationCanceledException携带了已取消的canceledToken，符合当前框架版本的放宽判定规则，因此Task被标记为Canceled状态：

• Wait()触发Task.Exception包装逻辑，拿到嵌套在AggregateException内的TaskCanceledException。
• await直接提取原始抛出的OperationCanceledException，因此两种等待方式抛出的异常类型不同。

场景2：调用ThrowIfCancellationRequested() #

该方法本质就是抛出携带对应Token的OperationCanceledException，和手动构造异常没有区别。最终Task进入Faulted状态的原因是：调用Task.Run时没有将canceledToken作为参数传入调度器，当前框架版本未触发放宽规则，不满足取消状态判定条件，因此被判定为执行出错进入Faulted状态。
Task处于Faulted状态时，框架不会做取消异常的特殊包装，因此无论用哪种方式等待，抛出的都是原始的OperationCanceledException（Wait()仅额外套一层AggregateException，内层异常类型一致）。

场景3：返回Task.FromCanceled() #

Task.FromCanceled是框架提供的显式构造已取消Task的方法，生成的Task默认标记为Canceled状态，且内部存储的取消异常本身就是框架构造的TaskCanceledException，因此无论用哪种方式等待，抛出的异常类型一致。

异常表现统一方案 #

若要对外暴露的异步API异常表现一致，可按如下方式处理：

• 所有取消场景统一将关联的CancellationToken传入Task.Run等调度方法，或直接使用Task.FromCanceled构造返回值，保证取消状态判定逻辑统一。
• API最外层添加统一异常拦截，将所有取消相关的异常转换为约定的统一类型后再抛出。

内容的提问来源于stack exchange，提问作者Theodor Zoulias