2

在浏览网络上的资源时，我遇到了很多样板代码，如下所示：

假设我们有一些public class CustomObject: IDisposable，它有一堆方法。

现在，这些方法中的每一个都有默认的健全性检查：

if (inputBuffer == null)
    throw new ArgumentNullException("inputBuffer");
if (outputBuffer == null)
    throw new ArgumentNullException("outputBuffer");
if (inputCount < 0)
    throw new ArgumentException("inputCount", "< 0");

但是（由于IDisposable接口实现）每个方法都添加了以下检查：

if (disposed)
    throw new ObjectDisposedException("MethodName");

现在 -这是一种常见的做法吗？我应该开始重新设计我的旧一次性课程并实施这些检查吗？

4

3 回答 3

3

现在 - 这是一种常见的做法吗？

是的，推荐。对于几乎所有成员。如果您的类是 IDisposable 并且在Dispose() 之后调用了任何需要资源的方法，则调用代码中存在严重的逻辑错误。你的任务是发出信号。

但请注意，可能有一些方法（或属性）并不严重依赖于拥有的资源，它们可以被认为在 Dispose() 之后调用是安全的。例如IsOpen函数/属性。它可以简单地返回false，不需要异常。

但是您不应该将IsDisposed 检查放入 Dispose() 本身，指导原则是多次调用 Dispose() 应该是安全的。

我应该开始重新设计我的旧一次性课程并实施这些检查吗？

总的来说是个好主意。是否值得努力取决于你。

于 2011-11-24T12:32:33.417 回答
2

这取决于您的使用情况，如果有疑问，添加它并没有什么坏处。

对于打算由其他程序（例如库和框架）使用的类，我将始终执行此检查并抛出正确的异常，因为这将有助于其他应用程序诊断错误并使该类更加健壮。

对于仅打算由我的应用程序使用的内部类，您可以跳过检查在调用方法时错误是否会很快出现。例如，如果类中的每个方法都使用一个流，并且该流被释放或设置为 null，它会很快导致异常。

如果内部类具有不会出错的方法，我将始终使用显式检查，因为我不希望某些方法在对象被释放后仍然有效（除了显式允许它的方法作为IsDisposed）。

进行显式检查确实具有显式记录在释放对象后允许调用哪些方法的优点。更重要的是，如果您在未调用的方法顶部添加注释GuardDisposed以声明它是允许的，那么任何不以注释开头的方法GuardDisposed或注释都可以被视为可疑。

为了实际实现检查，我更喜欢将其移至单独的方法并像断言一样使用它，例如

public class Foo
{
    private bool disposed;

    public void DoSomething ()
    {
        GuardDisposed ();
    }

    protected void GuardDisposed ()
    {
        if (disposed)
            throw new ObjectDisposedException (GetType ().Name);
    }
}
于 2011-11-24T12:35:32.450 回答
0

您放入 Dispose() （通常）方法中的代码是为了确保它不会在单个实例上被显式地（和/或）显式地调用一次以上。

他们使用它以防您在该方法中执行可以执行一次的操作（DeleteFile、CloseTransaction ...）以及您可能想到的任何其他操作，即不应在您的应用程序域中执行两次。

因此，如果这是一种常见做法：我会说，这取决于您的应用程序要求。

于 2011-11-24T12:18:32.510 回答