在AsyncDispose中处理异常的正确方法

在切换到新的.NET Core 3的过程中IAsynsDisposable，我偶然发现了以下问题。

问题的核心：如果DisposeAsync引发异常，则此异常隐藏await using-block 内部引发的所有异常。

class Program 
{
    static async Task Main()
    {
        try
        {
            await using (var d = new D())
            {
                throw new ArgumentException("I'm inside using");
            }
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message); // prints I'm inside dispose
        }
    }
}

class D : IAsyncDisposable
{
    public async ValueTask DisposeAsync()
    {
        await Task.Delay(1);
        throw new Exception("I'm inside dispose");
    }
}

被捕获的是AsyncDispose-exception（如果引发了），并且await using只有AsyncDispose不引发时才从内部发出异常。

但是，我还是更喜欢它：await using如果可能的话，从块中获取异常，并且DisposeAsync仅在await using块成功完成时才使用-exception 。

基本原理：想象一下，我的班级D使用一些网络资源并远程订阅了一些通知。内部的代码await using可能会出错，并导致通信通道失败，此后，Dispose中试图正常关闭通信（例如，取消订阅通知）的代码也会失败。但是第一个例外为我提供了有关该问题的真实信息，第二个例外只是次要问题。

在另一种情况下，当主要部分通过并且处置失败时，真正的问题就在内部DisposeAsync，因此相关的例外DisposeAsync。这意味着仅仅抑制内部的所有异常DisposeAsync并不是一个好主意。

我知道非异步情况也存在相同的问题：in中finally的exception覆盖in中的exception try，这就是为什么不建议使用in的原因Dispose()。但是，通过网络访问类，抑制关闭方法中的异常看起来一点也不好。

可以使用以下帮助程序解决问题：

static class AsyncTools
{
    public static async Task UsingAsync<T>(this T disposable, Func<T, Task> task)
            where T : IAsyncDisposable
    {
        bool trySucceeded = false;
        try
        {
            await task(disposable);
            trySucceeded = true;
        }
        finally
        {
            if (trySucceeded)
                await disposable.DisposeAsync();
            else // must suppress exceptions
                try { await disposable.DisposeAsync(); } catch { }
        }
    }
}

并像这样使用

await new D().UsingAsync(d =>
{
    throw new ArgumentException("I'm inside using");
});

这有点丑陋（并且禁止在using块内使用类似早日返回的功能）。

是否有一个好的，规范的解决方案，await using如果可能的话？我在互联网上的搜索甚至都没有找到讨论此问题的信息。

有一些您要浮出水面的异常（中断当前请求，或降低流程），还有一些您的设计预期会在某些时候发生的异常，您可以对其进行处理（例如重试并继续）。

但是，区分这两种类型取决于代码的最终调用者-这是异常的全部要点，从而将决定权交给调用者。

有时，调用者会更加重视显示原始代码块中的异常，有时还会显示中的异常Dispose。没有通用的规则来决定哪个优先。CLR在同步和非异步行为之间至少是一致的（如您所指出的）。

不幸的是，现在我们不得不AggregateException代表多个异常，无法对其进行改进以解决此问题。也就是说，如果一个异常已经在发生中，并且抛出了另一个异常，则将它们合并为一个AggregateException。catch可以修改该机制，以便在编写catch (MyException)时可以捕获任何AggregateException包含type异常的内容MyException。但是，这种想法还带来了其他各种复杂情况，现在修改如此基本的内容可能太冒险了。

您可以改进UsingAsync以支持早日返回值：

public static async Task<R> UsingAsync<T, R>(this T disposable, Func<T, Task<R>> task)
        where T : IAsyncDisposable
{
    bool trySucceeded = false;
    R result;
    try
    {
        result = await task(disposable);
        trySucceeded = true;
    }
    finally
    {
        if (trySucceeded)
            await disposable.DisposeAsync();
        else // must suppress exceptions
            try { await disposable.DisposeAsync(); } catch { }
    }
    return result;
}

也许您已经了解了为什么会发生这种情况，但是值得详细说明。这种行为并非特定于await using。也会发生一个普通的using块。因此，尽管我Dispose()在这里说，这同样适用DisposeAsync()。

一个using块仅仅是一个语法糖try/ finally块，作为文档的备注节说。您看到的是因为该finally块始终运行，即使发生异常也是如此。因此，如果发生异常，并且没有任何catch块，则将该异常搁置，直到该finally块运行，然后引发该异常。但是，如果中发生异常finally，您将永远看不到旧的异常。

您可以通过以下示例看到此内容：

try {
    throw new Exception("Inside try");
} finally {
    throw new Exception("Inside finally");
}

不要紧，是否Dispose()还是DisposeAsync()被称为内finally。行为是相同的。

我的第一个念头是：不要扔进去Dispose()。但是，在回顾了一些微软自己的代码之后，我认为这取决于。

看看它们对的实现FileStream。既是同步Dispose()方法，又DisposeAsync()实际上可以引发异常。同步Dispose()确实会故意忽略某些异常，但不是全部。

但是我认为重要的是要考虑班级的性质。在一个FileStream，例如，Dispose()将刷新缓冲器到文件系统。这是一项非常重要的任务，您需要知道该操作是否失败。您不能只是忽略这一点。

但是，在其他类型的对象中，当您调用时Dispose()，您实际上不再使用该对象。调用Dispose()实际上只是意味着“该对象对我已经死了”。也许它会清理一些分配的内存，但是失败不会以任何方式影响应用程序的运行。在这种情况下，您可能决定忽略内的异常Dispose()。

但无论如何，如果您想区分内的异常using或来自的异常Dispose()，则在块内外都需要一个try/ 块：catchusing

try {
    await using (var d = new D())
    {
        try
        {
            throw new ArgumentException("I'm inside using");
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message); // prints I'm inside using
        }
    }
} catch (Exception e) {
    Console.WriteLine(e.Message); // prints I'm inside dispose
}

否则您将无法使用using。写出一个try/ catch/ finally阻止自己，在那里你赶上任何异常finally：

var d = new D();
try
{
    throw new ArgumentException("I'm inside try");
}
catch (Exception e)
{
    Console.WriteLine(e.Message); // prints I'm inside try
}
finally
{
    try
    {
        if (D != null) await D.DisposeAsync();
    }
    catch (Exception e)
    {
        Console.WriteLine(e.Message); // prints I'm inside dispose
    }
}

using是有效的异常处理代码（try ... finally ... Dispose（）的语法糖）。

如果您的异常处理代码引发了Exceptions，则某些事情将被彻底废除。

任何其他事情甚至使您无法进入那里，也都不再重要。错误的异常处理代码将以一种或另一种方式隐藏所有可能的异常。异常处理代码必须是固定的，具有绝对优先级。否则，您将永远得不到足够的调试数据来解决实际问题。我经常看到它做错了。它就像处理裸露的指针一样容易出错。因此，经常有两篇关于主题I的文章，它们可能会帮助您解决任何潜在的设计误解：

• 异常的分类以及应该捕获的异常
• 分类无法涵盖的一般良好做法

根据异常分类，如果您的异常处理/ Dipose代码抛出异常，则需要执行以下操作：

对于“致命”，“骨头”和“激怒”而言，解决方案是相同的。

即使代价高昂，也必须避免外来异常。我们仍然使用日志文件而不是日志数据库来记录异常是有原因的-DB Opeartions只是容易遇到外源问题的方法。日志文件就是一种情况，我什至不介意是否保持文件句柄打开整个运行时。

如果您要关闭连接，则不必担心另一端。像UDP一样处理它：“我将发送信息，但是我不在乎对方是否得到了它。” 处置是关于清理正在处理的客户端/客户端上的资源。

我可以尝试通知他们。但是清理服务器/ FS端的东西吗？这就是他们的超时和他们的异常处理负责。

您可以尝试使用AggregateException并修改您的代码，如下所示：

class Program 
{
    static async Task Main()
    {
        try
        {
            await using (var d = new D())
            {
                throw new ArgumentException("I'm inside using");
            }
        }
        catch (AggregateException ex)
        {
            ex.Handle(inner =>
            {
                if (inner is Exception)
                {
                    Console.WriteLine(e.Message);
                }
            });
        }
        catch (Exception e)
        {
            Console.WriteLine(e.Message);
        }
    }
}

class D : IAsyncDisposable
{
    public async ValueTask DisposeAsync()
    {
        await Task.Delay(1);
        throw new Exception("I'm inside dispose");
    }
}

https://docs.microsoft.com/ru-ru/dotnet/api/system.aggregateexception?view=netframework-4.8

https://docs.microsoft.com/ru-ru/dotnet/standard/parallel-programming/exception-handling-task-parallel-library