C# 异步异常包装

Question

我一直在研究 .NET 4.6.1 中的异步调用，我想知道抛出错误的正确方法是来自期望异步方法但实际上是同步的接口(interface)的实现者。例如:

public interface ISomeInterface
{
    Task ExecuteAsync();
}

public class SomeClass : ISomeInterface
{
    public Task ExecuteAsync()
    {
        return Task.FromException(new Exception());
    }
}

我发现了 Task.FromException here .

所以 .NET 4.6 似乎仍然建议包装异常。但是我可以只写下面的代码:

public class SomeClass : ISomeInterface
{
    public Task ExecuteAsync()
    {
        throw new Exception();
    }
}

当我使用 try/catch block 调用第二个实现时，客户端捕获了 Exception，我认为这就是我们首先使用 Task.FromException 的原因，而且它还包含原始异常的整个调用堆栈(而方法一只有一个堆栈跟踪到客户端的等待操作)。似乎第二种方法更好，但似乎每个人都在使用第一种方法。由于 async 的实现发生变化，方法一现在是否已过时，或者我是否遗漏了什么？

我还在堆栈跟踪中注意到 async 方法现在不会在调用之间引入任何额外的帧。我假设这只是为了简化堆栈跟踪的阅读？

Answer 1

what the correct way to throw errors is from an implementer of an interface that expects an asynchronous method but is in fact synchronous.

如您所见，您可以直接抛出异常，也可以将异常放在返回的 Task 上。

请注意，这确实会改变观察到异常的地方:

var task = obj1.ExecuteAsync();
await task;

如果直接抛出异常，则在调用 ExecuteAsync 时抛出。如果异常发生在返回的任务上，它会在该任务被 await 时抛出。 大多数时间，任务在调用方法后立即await，但并非总是如此(例如，在Task.WhenAll 类情景)。

使用异步(任务返回)API，返回的任务表示方法的执行。 async-实现的 API 总是在返回的任务上放置任何异常。所以，我会说任务返回 API 的期望是任务会收到异常。

在boneheaded exceptions的情况下, 你可以用任何一种方式来证明这一点。由于异常表示代码错误，因此何时引发并不重要。例如，LINQ to Objects 总是会立即引发愚蠢的异常，而不是在枚举其返回的枚举器时。

但是，对于所有其他类型的异常，它们肯定应该继续返回的Task。就个人而言，我只是将所有异常放在返回的 Task 上。