IDisposable 在方法中创建并返回

Question

我很高兴编写了一个运行良好且在运行时不会出现任何异常的项目。所以我决定运行静态代码分析工具（我使用的是 Visual Studio 2010）。结果发现违反了CA2000规则，消息如下：

警告 - CA2000：Microsoft.Reliability：在方法“Bar.getDefaultFoo()”中，在对对象“new Foo()”的所有引用超出范围之前调用 System.IDisposable.Dispose。

引用的代码如下：

private static IFoo getDefaultFoo()
{
    return (Baz.canIDoIt()) ? new Foo() : null;
}

我自己想：也许条件表达式会破坏逻辑（我的或验证器的）。改成这样：

private static IFoo getDefaultFoo()
{
    IFoo ret = null;
    if (Baz.canIDoIt())
    {
        retFoo = new Foo();
    }
    return ret;
}

同样的事情又发生了，但现在对象被称为retFoo。我用谷歌搜索，我已经 msdn'ed，我已经 stackoverflow'ed。找到this article。创建对象后，我不需要执行任何操作。我只需要返回对它的引用。但是，我尝试应用 OpenPort2 示例中建议的模式。现在代码如下所示：

private static IFoo getDefaultFoo()
{
    Foo tempFoo = null;
    Foo retFoo = null;
    try
    {
        if (Baz.canIDoIt())
        {
            tempFoo = new Foo();
        }
        retFoo= tempFoo;
        tempFoo = null;
    }
    finally
    {
        if (tempFoo != null)
        {
            tempFoo.Dispose();
        }
    }
    return retFoo;
}

同样的消息再次出现，但 tempFoo 变量这次违反了规则。因此，基本上，代码变得扭曲、更长、有点不合理、不必要的复杂，并且执行相同的操作，但速度较慢。

我还发现了this question，其中相同的规则似乎以类似的方式攻击有效代码。并且建议提问者忽略警告。我还阅读了this thread 和大量类似的问题。

有什么我错过的吗？规则是否被窃听/无关？我该怎么办？忽视？以某种神奇的方式处理？也许应用一些设计模式？

编辑：

在 Nicole 的要求下，我以我也尝试使用的形式提交了整个相关代码。

public class DisposableFooTest
{
    public interface IFoo
    {
        void bar();
    }

    public class Foo : IFoo, IDisposable
    {
        public void bar()
        {
            Console.Out.WriteLine("Foo baring now");
        }

        public void Dispose()
        {
            // actual Dispose implementation is irrelevant, or maybe it is?
            // anyway I followed microsoft dispose pattern
            // with Dispose(bool disposing)
        }
    }

    public static class Baz
    {
        private static bool toggle = false;
        public static bool canIDoIt()
        {
            toggle ^= true;
            return toggle;
        }
    }

    private static IFoo getDefaultFoo()
    {
        IFoo result = null;
        try
        {
            if (Baz.canIDoIt())
            {
                result = new Foo();
            }

            return result;
        }
        catch
        {
            if (result != null)
            {
                (result as IDisposable).Dispose();
                // IFoo does not inherit from IDisposable, hence the cast
            }

            throw;
        }
    }

    public static void Main()
    {
        IFoo bar = getDefaultFoo();
    }
}

分析报告包含以下内容：
`CA2000：Microsoft.Reliability：在方法“DisposableFooTest.getDefaultFoo()”中，在对对象“result”的所有引用超出范围之前调用 System.IDisposable.Dispose。 %%projectpath%%\DisposableFooTest.cs 44 测试

编辑2：

以下方法解决了 CA2000 问题：

private static IFoo getDefaultFoo()
{
    Foo result = null;
    try
    {
        if (Baz.canIDoIt())
        {
            result = new Foo();
        }
        return result;
    }
    finally
    {
        if (result != null)
        {
            result.Dispose();
        }
    }
}

很遗憾，我不能走那条路。更重要的是，我更希望遵循面向对象的原则、良好实践和指南来简化代码，使其具有可读性、可维护性和可扩展性。我怀疑有人会按预期阅读它：如果可能，给它 Foo，否则为 null。

Answer 1

这是一个误报警告。如果IFoo 实现IDisposable，则无法返回IFoo 的适当实例，而代码分析工具会警告您未正确处理它。

代码分析不会分析您的意图或逻辑，它只是尝试警告常见错误。在这种情况下，“看起来”您正在使用IDisposable 对象而不是调用Dispose()。在这里，您按设计这样做，因为您希望您的方法返回一个新实例并将其作为工厂方法的一种形式。

Answer 2

这里的问题不是您的 C# 代码明确执行的操作，而是生成的 IL 使用多条指令来完成 C# 代码中的一个“步骤”。

例如，在第三个版本中（使用 try/finally），return retFoo 行实际上涉及分配由编译器生成的附加变量，而您在原始代码中看不到该变量。由于此分配发生在 try/finally 块之外，它确实会引入未处理异常的可能性，从而使您的一次性 Foo 实例“孤立”。

这是一个可以避免潜在问题（并通过 CA2000 筛选）的版本：

private static IFoo getDefaultFoo()
{
    IFoo result = null;
    try
    {
        if (Baz.canIDoIt())
        {
            result = new Foo();
        }

        return result;
    }
    catch
    {
        if (result != null)
        {
            result.Dispose();
        }

        throw;
    }
}

显然，与第一个版本相比，这在一定程度上影响了可读性和可维护性，因此您必须确定孤立的可能性以及不处置孤立的后果是否真的值得更改代码，或者是否抑制在这种特殊情况下，违反 CA2000 可能更可取。

Answer 3

当返回 IDisposable 对象时，如果值为 null，则处置该对象并在方法中返回 null - 这应该清除与您的“私有静态 IFoo getDefaultFoo()”相关的“警告/建议”消息方法。当然，您仍然需要在调用例程中将对象作为 IDisposable（使用或处置）来处理。

private static IFoo getDefaultFoo()
{
    IFoo ret = null;
    if (Baz.canIDoIt())
    {
        retFoo = new Foo();
    }
    return ret;
}

改成

private static IFoo getDefaultFoo()
{
    IFoo ret = null;
    if (Baz.canIDoIt())
    {
        retFoo = new Foo();
    }
    if (ret == null)
    {
        ret.dispose();
        return null;
    }
    else
        return ret;
}

Answer 4

静态分析基本上是在抱怨，原因如下：

1. IFoo 接口不继承自IDisposable，
2. 但是您返回的是一个必须处理的具体实现，而调用者将无法知道这一点。

换句话说，您的GetDefaultFoo 方法的调用者需要一个IFoo 实现，但不知道您的实现需要显式处置，因此可能不会处置它。如果这是其他库中的常见做法，您将不得不手动检查项目是否实现了IDisposable，因为任何可能的接口的每个可能实现。

显然，这有问题。

恕我直言，解决此问题的最简单方法是让 IFoo 继承自 IDisposable：

public interface IFoo : IDisposable
{
    void Bar();
}

这样，调用者知道他们收到的任何可能的实现都必须被处理掉。这也将允许静态分析器检查您使用 IFoo 对象的所有位置，并在您未正确处理它们时警告您。