在展开嵌套的“using”语句时处理“Dispose”引发的异常

Question

显然，在使用嵌套的using 语句时，某些异常可能会丢失。考虑这个简单的控制台应用程序：

using System;

namespace ConsoleApplication
{
    public class Throwing: IDisposable
    {
        int n;

        public Throwing(int n)
        {
            this.n = n;
        }

        public void Dispose()
        {
            var e = new ApplicationException(String.Format("Throwing({0})", this.n));
            Console.WriteLine("Throw: {0}", e.Message);
            throw e;
        }
    }

    class Program
    {
        static void DoWork()
        {
            // ... 
            using (var a = new Throwing(1))
            {
                // ... 
                using (var b = new Throwing(2))
                {
                    // ... 
                    using (var c = new Throwing(3))
                    {
                        // ... 
                    }
                }
            }
        }

        static void Main(string[] args)
        {
            AppDomain.CurrentDomain.UnhandledException += (sender, e) =>
            {
                // this doesn't get called
                Console.WriteLine("UnhandledException:", e.ExceptionObject.ToString());
            };

            try
            {
                DoWork();
            }
            catch (Exception e)
            {
                // this handles Throwing(1) only
                Console.WriteLine("Handle: {0}", e.Message);
            }

            Console.ReadLine();
        }
    }
}

Throwing 的每个实例在被处理时都会抛出。 AppDomain.CurrentDomain.UnhandledException 永远不会被调用。

输出：

投掷：投掷(3) 投掷：投掷(2) 投掷：投掷(1) 手柄：投掷(1)

我希望至少能够记录丢失的Throwing(2) 和Throwing(3)。 如何做到这一点，而不为每个 using 使用单独的 try/catch（这会破坏 using 的便利性）？

在现实生活中，这些对象通常是我无法控制的类的实例。他们可能会或可能不会抛出，但如果他们这样做，我希望可以选择观察此类异常。

这个问题是在我查看reducing the level of nested using 时出现的。有一个neat answer 建议聚合异常。有趣的是，这与嵌套 using 语句的标准行为有何不同。

[EDITED] 这个问题似乎密切相关： Should you implement IDisposable.Dispose() so that it never throws?

Answer 1

对此有代码分析器警告。 CA1065，“不要在意外位置引发异常”。 Dispose() 方法在该列表中。框架设计指南第 9.4.1 章中也有强烈警告：

避免在 Dispose(bool) 中引发异常，除非在包含进程已损坏的严重情况下（泄漏、不一致的共享状态等）。

这是错误的，因为 using 语句在 finally 块内调用 Dispose()。 finally 块中引发的异常可能会产生令人不快的副作用，如果在堆栈因异常而展开时调用了 finally 块，它替换活动异常。正是您在这里看到的情况。

复制代码：

class Program {
    static void Main(string[] args) {
        try {
            try {
                throw new Exception("You won't see this");
            }
            finally {
                throw new Exception("You'll see this");
            }
        }
        catch (Exception ex) {
            Console.WriteLine(ex.Message);
        }
        Console.ReadLine();
    }
}

Answer 2

您注意到的是Dispose 和using 设计中的一个基本问题，目前还没有很好的解决方案。恕我直言，最好的设计是拥有一个Dispose 的版本，它接收任何可能挂起的异常（或null，如果没有挂起）作为参数，并且可以记录或封装该异常，如果它需要抛出它自己的一个。否则，如果您同时控制了可能导致using 和Dispose 内异常的代码，您可以使用某种外部数据通道让Dispose 知道内部异常，但那是相当的。

太糟糕了，没有适当的语言支持与finally 块相关联的代码（显式或通过using 隐式）知道相关联的try 是否正确完成，如果没有，出了什么问题。 Dispose 应该默默失败的想法是恕我直言，非常危险和错误的想法。如果一个对象封装了一个为写入而打开的文件，而Dispose 关闭了该文件（常见模式）并且无法写入数据，则正常返回Dispose 调用会导致调用代码相信数据已写入正确，可能允许它覆盖唯一好的备份。此外，如果文件应该被显式关闭并且调用Dispose而不关闭文件应该被认为是一个错误，这意味着Dispose应该抛出异常，如果受保护块正常完成，但如果受保护块未能调用Close，因为首先发生了异常，让Dispose 抛出异常将非常无益。

如果性能不重要，您可以在 VB.NET 中编写一个包装器方法，该方法将接受两个委托（Action 和一个 Action<Exception> 类型），在 try 块中调用第一个委托，然后在 finally 块中调用第二个，但在 try 块中发生的异常（如果有）。如果包装器方法是用 VB.NET 编写的，它可以发现并报告发生的异常，而不必捕获并重新抛出它。其他模式也是可能的。包装器的大多数用法都会涉及到闭包，这很糟糕，但包装器至少可以实现适当的语义。

另一种包装器设计可以避免闭包，但需要客户端正确使用它，并且对不正确使用提供的保护很少，会产生如下使用情况：

var dispRes = new DisposeResult();
... 
try
{
  .. the following could be in some nested routine which took dispRes as a parameter
  using (dispWrap = new DisposeWrap(dispRes, ... other disposable resources)
  {
    ...
  }
}
catch (...)
{
}
finally
{
}
if (dispRes.Exception != null)
  ... handle cleanup failures here

这种方法的问题是无法确保任何人都会评估dispRes.Exception。可以使用终结器记录 dispRes 未经检查就被放弃的情况，但是无法区分发生这种情况的情况，因为异常将代码踢出 if 测试之外，或者因为程序员只是忘记支票了。

PS--Dispose 真正应该知道是否发生异常的另一种情况是 IDisposable 对象用于包装锁或其他范围，其中对象的不变量可能会暂时失效，但预计会在代码离开之前恢复范围。如果发生异常，代码通常不应期望解决异常，但仍应采取行动基于它，既不保持也不释放锁，而是invalidated，因此任何现在或将来的获取它的尝试都会抛出异常。如果以后没有尝试获取锁或其他资源，则它无效的事实不应中断系统操作。如果该资源对程序的某些部分至关重要，则使其无效将导致程序的该部分死亡，同时最大限度地减少它对其他任何部分造成的损害。我知道用良好的语义真正实现这种情况的唯一方法是使用 icky 闭包。否则，唯一的替代方法是要求显式的 invalidate/validate 调用，并希望在资源无效的代码部分中的任何 return 语句之前都调用 validate。

Answer 3

也许一些帮助函数可以让你编写类似于using的代码：

 void UsingAndLog<T>(Func<T> creator, Action<T> action) where T:IDisposabe
 {  
      T item = creator();
      try 
      {
         action(item);
      }
      finally
      { 
          try { item.Dispose();}
          catch(Exception ex)
          {
             // Log/pick which one to throw.
          } 
      }      
 }

 UsingAndLog(() => new FileStream(...), item => 
 {
     //code that you'd write inside using 
     item.Write(...);
 });

请注意，我可能不会走这条路，只是让来自Dispose 的异常覆盖我在正常using 内的代码中的异常。如果库从Dispose 抛出反对强烈建议不要这样做，那么很有可能它不是唯一的问题，并且需要重新考虑此类库的有用性。