在终结器中抛出异常以强制 Dispose 调用：

Question

这是我认为推荐的典型 IDisposable 实现：

~SomeClass() {
    Dispose(false);
}

public void Dispose() {
    GC.SuppressFinalize(this);
    Dispose(true);
}

protected virtual void Dispose(bool isDisposing) {
    if(isDisposing) {
        // Dispose managed resources that implement IDisposable.
    }
    // Release unmanaged resources.
}

现在，据我了解，终结器背后的想法是，如果我不调用 Dispose，我的非托管资源仍将被正确释放。但是，据我所知，人们普遍认为不对实现 IDisposable 的对象调用 Dispose 可能是一个错误。

是否有特别的理由不完全接受这一点而改为这样做？

~SomeClass() {
    throw new NotImplementedException("Dispose should always be called on this object.");
}

public virtual void Dispose() {
    GC.SuppressFinalize(this);

    // Dispose managed resources that implement IDisposable.

    // Release unmanaged resources.
}

Answer 1

从 .NET 2.0 及更高版本开始，如果未覆盖默认策略，则在终结器 causes the process to terminate 中引发未处理的异常。

据我了解，Finalizer 不是应该抛出异常的预期位置。我认为Dispose() 方法可能由于意外原因（线程中止，...）而未被调用，只要终结器正确执行，仍然可以从中进行干净恢复。

Answer 2

在终结器中抛出异常几乎总是一个坏主意。

即使在某些情况下它实际上会达到预期的结果（导致程序员被通知问题而不会搞砸其他任何事情），终结器无法知道什么时候会发生案例。

更好的方法是使用一种方法来指示（可能通过抛出任何异常）是否有任何对象被错误地丢弃；可以在程序结束时调用该方法，或者在创建新对象时调用该方法。这可能会导致在与被放弃的特定实例无关的部分代码中引发异常，但这仍然可能比在终结器上下文中引发异常更好。

Answer 3

从终结器中抛出异常是您做过的最糟糕的事情之一。它可能导致几种不同的行为。该异常可能会导致 ExecutionEngine 崩溃，从而降低整个进程，您可能会阻止终结器导致 OutOfMemory (OOM) 崩溃等。不要忘记终结器在单个线程上运行并且是最重要的线程之一- 你不希望它搞砸了。

Answer 4

由于开发人员倾向于变得懒惰并忽略任何可以忽略的警告，而且 IIS7.5 应用程序默认完全忽略 Debug.Fail 我也使用相同的模式。除了一个例外：

我只在调试版本中这样做，因为它对发布版本没有任何好处。此外，它从不直接保存非托管资源的类中删除了慢速终结器。

public void Dispose()
{
    // Do your dispose stuff here
#if DEBUG
    GC.SuppressFinalize(this);
}
~MyClass()
{   throw new ObjectNotDisposedException(); // This class is not intended to be used without Dispose.
#endif
}

在某些情况下，丢失的 dispose 可能会真正占用应用程序，例如远程事务上下文。在这种情况下，终止并没有什么更糟的，而且会让懒惰的开发人员感到紧张。我总是喜欢把问题带回源头。