我应该如何处理 Dispose() 方法中的异常？

Question

我想提供一个类来管理临时目录的创建和后续删除。理想情况下，我希望它可以在 using 块中使用，以确保无论我们如何离开该块，目录都会被再次删除：

static void DoSomethingThatNeedsATemporaryDirectory()
{
    using (var tempDir = new TemporaryDirectory())
    {
        // Use the directory here...
        File.WriteAllText(Path.Combine(tempDir.Path, "example.txt"), "foo\nbar\nbaz\n");
        // ...
        if (SomeCondition)
        {
            return;
        }
        if (SomethingIsWrong)
        {
            throw new Exception("This is an example of something going wrong.");
        }
    }
    // Regardless of whether we leave the using block via the return,
    // by throwing and exception or just normally dropping out the end,
    // the directory gets deleted by TemporaryDirectory.Dispose.
}

创建目录没有问题。问题是Dispose方法怎么写。当我们尝试删除该目录时，可能会失败；例如，因为我们仍然有一个文件在其中打开。但是，如果我们允许异常传播，它可能会掩盖 using 块内发生的异常。特别是，如果 using 块内发生异常，则可能导致我们无法删除目录，但如果我们屏蔽它，我们就丢失了解决问题的最有用信息。

看来我们有四个选择：

1. 尝试删除目录时捕获并吞下任何异常。我们可能没有意识到我们未能清理临时目录。
2. 当抛出异常时，以某种方式检测 Dispose 是否作为堆栈展开的一部分运行，如果是，则抑制 IOException 或抛出一个合并 IOException 和抛出的其他异常的异常。甚至可能根本不可能。 （我想到这一点的部分原因是Python的上下文管理器是可能的< /a>，这在很多方面类似于与 C# 的 using 语句一起使用的 .NET 的 IDisposable。）
3. 切勿抑制 IOException 导致删除目录失败。如果在 using 块内抛出异常，我们将隐藏它，尽管它很可能比 IOException 具有更多的诊断价值。
4. 放弃在Dispose方法中删除目录。该类的用户必须对请求删除目录负责。这似乎并不令人满意，因为创建该类的很大一部分动机是为了减轻管理此资源的负担。也许有另一种方法可以提供此功能而又不会很容易搞砸？

这些选项之一显然是最好的吗？有没有更好的方法在用户友好的 API 中提供此功能？

Answer 1

不要将其视为实现 IDisposable 的特殊类，而应考虑正常程序流的情况：

Directory dir = Directory.CreateDirectory(path);
try
{
    string fileName = Path.Combine(path, "data.txt");
    File.WriteAllText(fileName, myData);
    UploadFile(fileName);
    File.Delete(fileName);
}
finally
{
    Directory.Delete(dir);
}

它应该如何表现？这是完全相同的问题。您是否按原样保留 finally 块的内容，从而可能掩盖 try 块中发生的异常，或者包装 Directory.Delete 在它自己的 try-catch 块中，吞下任何异常以防止屏蔽原始异常？

我认为没有任何正确的答案 - 事实上，您只能有一个环境异常，因此您必须选择一个。然而，.NET Framework 确实开创了一些先例； WCF 服务代理 (ICommunicationObject) 就是一个示例。如果您尝试处置出现故障的通道，它会引发异常，并且将屏蔽堆栈上已有的任何异常。如果我没记错的话，TransactionScope 也可以做到这一点。

当然，WCF 中的这种行为一直是造成无尽混乱的根源。事实上，大多数人认为它即使没有损坏也很烦人。谷歌“WCF dispose mask”，你就会明白我的意思。因此，也许我们不应该总是尝试像微软一样做事。

就我个人而言，我认为 Dispose 永远不应该屏蔽堆栈上已有的异常。 using 语句实际上是一个 finally 块，并且大多数时候（总是存在边缘情况），您不想抛出（并且也没有捕获）finally 块中的异常。原因很简单，就是调试；弄清问题的根源可能极其 - 特别是生产中的问题，您无法单步查看源代码 - 当您甚至没有能力找出确切的位置时该应用程序失败。我以前也经历过这种情况，我可以自信地说，这会让你彻底疯掉。

我的建议是要么处理 Dispose 中的异常（当然，记录它），或者实际检查一下您是否是 由于异常已经处于堆栈展开场景，并且仅当您知道要屏蔽随后的异常时才执行它们。后者的优点是除非确实有必要，否则你不会吃例外；缺点是您在程序中引入了一些不确定的行为。又一个权衡。

大多数人可能只会选择前一个选项，并简单地隐藏 finally （或 using）中发生的任何异常。

Answer 2

最终，我建议最好遵循 FileStream< /code>作为指导，相当于选项 3 和 4：在 Dispose 方法中关闭文件或删除目录，并允许该操作中出现的任何异常冒泡（有效地吞掉 using 块内发生的任何异常），但如果组件的用户选择，则允许手动关闭资源，而不需要 using 块。

与 MSDN 的 FileStream 文档不同，我建议您详细记录用户选择使用 using 语句时可能发生的后果。

Answer 3

这里要问的一个问题是调用者是否可以有效地处理异常。如果用户无法合理执行任何操作（手动删除目录中正在使用的文件？），最好记录错误并忘记它。

为了涵盖这两种情况，为什么不使用两个构造函数（或构造函数的参数）？

public TemporaryDirectory()
: this( false )
{
}

public TemporaryDirectory( bool throwExceptionOnError )
{
}

然后，您可以将决定推给类的用户，以了解适当的行为可能是什么。

一个常见的错误是目录无法删除，因为其中的文件仍在使用中：您可以存储未删除的临时目录列表，并允许在程序关闭期间第二次显式尝试删除的选项（例如 TemporaryDirectory.txt）。 TidyUp() 静态方法）。如果有问题的目录列表非空，则代码可能会强制垃圾收集来处理未关闭的流。

Answer 4

您不能依赖于可以以某种方式删除目录的假设。一些其他进程/用户/任何东西都可以同时在其中创建文件。防病毒软件可能正忙于检查其中的文件等。

您可以做的最好的事情是不仅拥有临时目录类，而且拥有临时文件类（将在临时目录的 using 块内创建）临时文件类应该（尝试）删除 Dispose 上的相应文件，这样您至少可以尝试进行清理。

Answer 5

我想说，从锁定文件的析构函数中抛出异常可以归结为使用异常来报告预期结果 - 你不应该这样做。

但是，如果发生其他情况，例如变量为空，则可能确实出现错误，此时异常就有价值了。

如果您预计文件会被锁定，并且您或潜在的调用者可以对它们执行某些操作，那么您需要在类中包含该响应。如果您可以响应，则只需在一次性呼叫中进行即可。如果您的呼叫者能够响应，请为您的呼叫者提供一种方法，例如 TempfilesLocked 事件。

Answer 6

假设创建的目录位于系统临时文件夹中，例如 Path.GetTempPath 返回的文件夹，那么我将实现 Dispose 以便在删除时不会引发异常临时目录失败。

更新：
我会采取这个选项，因为操作可能会因为外部干扰而失败，例如来自另一个进程的锁定，而且由于该目录放置在系统临时目录中，我看不到抛出异常的优势。

对该异常的有效响应是什么？尝试再次删除该目录是不合理的，如果原因是来自另一个进程的锁定，那么它不直接在您的控制之下。

Answer 7

要在 using 语句中使用该类型，您需要实现 IDisposable 模式。

要创建目录本身，请使用Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)作为基础，并使用新的Guid作为名称。