Task.Delay.ContinueWith 和 async await with Task.Delay 之间有什么区别（如果有的话）？

Question

这是一个 linqpad 示例，展示了在短暂延迟后异步执行方法的两种方式。这两个例子似乎都做了同样的事情。我通常会实现第一个版本（使用 Task.Delay.ContinueWith），但我也看到了使用的第二个实现（异步等待）。这两种实现之间有什么区别吗？此场景的工作 Linqpad 示例：

void Main()
{
   // Using Task.Delay.ContinueWith...
   Task.Delay(1000).ContinueWith(t => DoSomething());       

   // ... vs async await. Note that I'm not awaiting the task here
   DoSomethingAsync();
}

public void DoSomething()
{
    "Doing Something...".Dump();
}

public async Task DoSomethingAsync()
{
    await Task.Delay(1000);

    "Doing Something...".Dump();
}

阅读这篇博文https://blogs.msdn.microsoft.com/pfxteam/2012/03/24/should-i-expose-asynchronous-wrappers-for-synchronous-methods/ 后，我认为第一个实现是“正确”的，因为“DoSomethingAsync()”实际上只是将方法卸载到线程池，并且博文指出：

“不应仅仅为了卸载目的而公开异步方法：同步方法的使用者可以通过使用专门针对异步处理同步方法的功能（例如 Task.Run）轻松实现这些好处。”

但是，StackOverflow 上的这个答案提出了第二种解决方案：

Delay then execute Task

这两种实现之间有什么实际区别吗？如果“异步等待”实现也有效（或更正确），返回的任务应该怎么做？我真的不想等待它，这是一个即发即弃的操作，但我也想处理任何可能引发的异常。

在第一个实现中，我知道我可以使用 ContinueWith, OnlyOnFaulted 来处理异常。

Answer 1

它们相似，但不完全相同。例如，在SynchronizationContext.Current 之前，async 方法的延续将被调度到此同步上下文，但ContinueWith 不会，并将在线程池线程上运行。虽然使用 ContinueWith 的另一个重载，但你可以让它做同样的事情：

.ContinueWith(t => DoSomething(), TaskScheduler.FromCurrentSynchronizationContext());

您可以使用await yourTask.ConfigureAwait(false) 阻止在异步版本中调度到同步上下文。

那么，异常处理就不同了。在async 版本中，会直接抛出异常，如果有多个异常（例如来自await Task.WhenAll） - 只会抛出第一个，其余的将被吞噬。很难错过这个例外。

在ContinueWith 版本中，抛出的异常用t.Exception 表示，它总是AggregateException，所以你必须解包它。另一方面 - 所有异常都存在（如果有多个）并且没有一个被吞下。但是，很容易忘记处理该异常。例如，在您问题中的代码中 - 您不处理 ContinueWith 中的异常，因此无论是否有异常，DoSomething() 继续都会被执行。在async 版本中，出现异常时不执行延续。

这两种实现都是“有效的”。您不应该忘记在这两种情况下处理异常。使用ContinueWith - 要么始终检查t.Exception，要么使用OnlyOnFaulted 安排单独的继续（并仅在此处检查）。如果是 async 版本 - 将正文包裹在 try-catch 块中。出于“一劳永逸”的性质 - 您无法在调用站点处理异常，但您不应完全放弃它们。

在您在短暂延迟后执行方法的特定情况下，我想说这只是一个偏好问题（捕获同步上下文的差异除外）。我个人更喜欢ContinueWith，它表达的意图更清晰，不需要语义不明确的单独方法。

Answer 2

ContinueWith() 允许您以“即发即弃”的方式链接任务。否则，您必须等待任务完成，然后执行下一个可等待操作（并且“等待”意味着您还必须使用“异步”修改调用方方法签名，这可能不太适合，比如说，事件处理程序)。