为何要使用CancellationToken.ThrowIfCancellationRequested方法？

这是个非常好的问题！很多刚接触.NET协作式取消机制的开发者都会有这样的疑惑——明明用个if判断就能退出循环，为啥要搞个异常出来？咱们来拆解这个设计的合理性和初衷：

先把你提供的示例代码和运行结果格式化后方便参考：

示例代码 #

using System;
using System.Threading;
using static System.Threading.Thread;
using static System.Console;

internal static class ThreadCancellation
{
    private static void Main()
    {
        var cancellationTokenSource = new CancellationTokenSource();
        var cancellationToken = cancellationTokenSource.Token;

        ThreadPool.QueueUserWorkItem(x => Counter(cancellationToken));
        ThreadPool.QueueUserWorkItem(x => CounterWithThrow(cancellationToken));

        Sleep(10);
        cancellationTokenSource.Cancel();
        Sleep(10);
    }

    private static void Counter(CancellationToken cancellationToken)
    {
        WriteLine($"Counter running on {CurrentThread.ManagedThreadId}.");
        while (!cancellationToken.IsCancellationRequested)
        {
            WriteLine($"Thread {CurrentThread.ManagedThreadId}: {DateTime.Now.Ticks}");
            Sleep(1);
        }
        WriteLine("Counter() was canceled");
    }

    private static void CounterWithThrow(CancellationToken cancellationToken)
    {
        WriteLine($"CounterWithThrow running on {CurrentThread.ManagedThreadId}.");
        try
        {
            while (true)
            {
                WriteLine($"Thread {CurrentThread.ManagedThreadId}: {DateTime.Now.Ticks}");
                cancellationToken.ThrowIfCancellationRequested();
                Sleep(1);
            }
        }
        catch (OperationCanceledException e)
        {
            WriteLine($"Thread {CurrentThread.ManagedThreadId}: Caught OperationCanceledException: {e.Message}");
        }
    }
}

运行结果 #

Counter running on 4.
CounterWithThrow running on 3.
Thread 4: 636619039468459034
Thread 3: 636619039468459034
Thread 4: 636619039468530368
Thread 3: 636619039468530368
Thread 4: 636619039468550400
Counter() was canceled
Thread 3: 636619039468550400
Thread 3: Caught OperationCanceledException: The operation was canceled.

现在逐一解答你的疑问：

1. 线程取消真的应该以异常形式处理吗？ #

当然应该——这是.NET协作式取消模型的标准化实现。协作式取消的核心是让线程自己决定何时响应取消，而异常是一种能穿透多层调用栈的统一信号：

• 如果你写的方法调用了其他子方法，子方法也可以检查取消令牌并抛出OperationCanceledException，这样整个调用链都会被中断，不用每个方法都手动判断IsCancellationRequested然后返回。
• 更重要的是，这个异常和.NET的Task异步模型深度绑定：当Task内部抛出这个异常时，Task会自动进入Canceled状态，而不是Faulted状态。上层代码可以通过Task.Status轻松区分“任务被取消”和“任务执行出错”两种情况，这是手动判断返回值做不到的。

2. 在catch块中进行资源清理比优雅退出更复杂？ #

其实恰恰相反，异常处理让资源清理更统一。比如你的线程中打开了文件流、数据库连接，用try/finally块可以确保不管是正常退出还是取消导致的异常，资源都会被清理：

private static void CounterWithThrow(CancellationToken cancellationToken)
{
    FileStream stream = null;
    try
    {
        stream = new FileStream("test.txt", FileMode.Open);
        while (true)
        {
            cancellationToken.ThrowIfCancellationRequested();
            // 执行文件操作
        }
    }
    catch (OperationCanceledException)
    {
        WriteLine("任务被取消");
    }
    finally
    {
        stream?.Dispose(); // 不管什么情况都会清理资源
    }
}

如果用手动判断的方式，你需要在每一处可能退出的地方都写清理代码，反而容易遗漏。

3. 用if语句就能完成的逻辑，为啥要用异常？ #

if语句只适合简单的循环场景，但复杂场景下异常的优势就体现出来了：

• 很多.NET内置API（比如Task.Delay(cancellationToken)、Stream.ReadAsync(..., cancellationToken)）都会在取消时自动抛出OperationCanceledException，你的代码可以直接和这些API无缝集成，不用单独处理不同的取消逻辑。
• 如果取消发生在某个耗时操作的中间（比如等待异步任务、网络请求），异常可以直接中断当前操作，而不用等待循环迭代到下一次判断的时机，响应更及时。

设计初衷总结 #

OperationCanceledException的设计初衷是为了提供一套统一、可扩展、与.NET生态深度整合的协作式取消机制：

• 统一：让所有需要响应取消的代码都遵循同一个标准，减少认知成本。
• 可扩展：取消信号能轻松穿透多层调用栈，支持复杂的调用场景。
• 整合：完美适配Task、异步编程模型以及大量内置API，让取消逻辑和业务逻辑更清晰地分离。

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