CancellationToken未抛异常求助：执行ThrowIfCancellationRequested时程序冻结

核心问题分析 #

1. 上层任务未等待，异常无法传递
   你用Task.Run启动后台任务，但没有等待任务完成，外层的try-catch根本捕获不到后台线程抛出的OperationCanceledException——因为Task.Run启动的线程是独立的，不等待的话，外层代码会直接走后续逻辑，异常只会在后台线程里“闷着”，不会冒泡到调用方的catch块。

2. 同步阻塞操作不响应取消信号
   代码里的stream.Read、Thread.Sleep都是同步阻塞调用，这些操作不会主动检测CancellationToken的取消状态，哪怕token已经被取消，它们还是会卡在阻塞环节，导致程序看起来“冻结”。

3. 取消逻辑冗余且异常抛出时机不对
   多处手动调用token.Cancel()后，最后又通过IsCancellationRequested判断再抛出异常，这个逻辑不仅冗余，而且因为任务没被等待，抛出的异常也传不回上层。

修复步骤 #

1. 上层调用改为异步等待

把包含try-catch的方法改成异步方法，用await等待Task.Run完成，这样异常才能被外层捕获：

// 注意：外层方法需要标记为async
try
{
    await Task.Run(() => SendData_DoWork(_tokenSource3));
}
catch (OperationCanceledException ex)
{
    SetText("Communivation error with device");
    SetText("");
}
finally
{
    _tokenSource3.Dispose(); // 原代码的token是笔误，应该用传入的_tokenSource3
}

2. 替换同步阻塞操作为支持取消的异步方法

把stream.Read改成ReadAsync并传入CancellationToken，让阻塞操作能响应取消信号：

// 替换原来的stream.Read同步调用
byteRead = await stream.ReadAsync(message, 0, 23, token2);

同时把Thread.Sleep改成await Task.Delay(xxx, token2)，同样让休眠操作能被取消打断。

3. 简化取消逻辑，直接抛出异常

去掉手动判断IsCancellationRequested的代码块，在需要取消的地方直接抛出异常，或者让异步操作自动触发取消异常：

// 比如检测到message[0] == 0x15时，直接触发取消并抛出
token.Cancel();
token2.ThrowIfCancellationRequested();

4. 统一清理Timer资源

把Timer的停止和释放放到finally块里，避免重复执行：

try
{
    timer.Interval = 10000;
    timer.Start();
    timer.Elapsed += OnTimerElapsed;
    // 其他业务逻辑...
}
catch (Exception ex)
{
    token.Cancel();
    throw; // 重新抛出异常，让上层的try-catch处理
}
finally
{
    timer.Stop();
    timer.Dispose();
}

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