Domanda

I have checked out the MSDN documentation, and adopted the recommended pattern in this code fragment:

  BitmapSymbols temp = null;
  try {
    using (var source = bitmaps.Symbols) {
      temp = new BitmapSymbols(source, sizeSymbols);
    }
    _bitmapSymbols = temp;
    temp           = null;
  } finally { 
    if (temp!=null) temp.Dispose(); 
  }

Does anyone know why temp is being reported on in this instance? I cannot see any execution paths in which temp is not disposed and not set to `null'. Thanks in advance for any assistance.

If I move the assignment from-and-to temp inside the using, the same warning is generated from FxCop.

The class BitmapSymbols implements IDisposable, and is a wrapper for a several collections of Bitmaps that ensures that they all get disposed at the same time.

Update:
The question was posed below:

Anyway, I do not see why you come up with this code rather than simply using:
_bitmapSymbols = new BitmapSymbols(source, sizeSymbols);

The reason is that not following the pattern can cause a memory leak if an exception occurs. I am writing a game that users might run for hours or days without restarting, so avoiding memory leaks is important for stability.

È stato utile?

Soluzione

I finally stumbled on the reasons (two separate cases) for the false positives even when the pattern recommended in the MSDN documentation here for CA2000 Dispose Objects Before Losing Scope is followed:

  1. If the name of the temporary disposable variable is not of the exact pattern shown, that is the string "temp" prepended in camelCase to the destination disposable, a false positive will be generated from a failure to recognize the recommended pattern. The false positive is easily eliminated with a name change.

  2. If the destination disposable variable is a property instead of a field or local, the pattern is not recognized. Eliminating the false positive here requires writing a single-use function like so:

    void SomeMethod() {
      // :  
      HexgridPath   = SetGraphicsPath();
      // :
    }
    
    GraphicsPath SetGraphicsPath() {
      GraphicsPath path     = null;
      GraphicsPath tempPath = null;
      try {
        tempPath  = new GraphicsPath();
        tempPath.AddLines(new Point[] {
          new Point(GridSize.Width*1/3,                0), 
          new Point(GridSize.Width*3/3,                0),
          new Point(GridSize.Width*4/3,GridSize.Height/2),
          new Point(GridSize.Width*3/3,GridSize.Height  ),
          new Point(GridSize.Width*1/3,GridSize.Height  ),
          new Point(                 0,GridSize.Height/2),
          new Point(GridSize.Width*1/3,                0)
        } );
        path     = tempPath;
        tempPath = null;
      } finally { if(tempPath!=null) tempPath.Dispose(); }
      return path;
    }
    

The first situation looks like a typical "junior-programmer's-first-assignment-just-out-of-school" error;

The second case is probably harder to fix, but is annoying.

Hopefully others who encounter these false positives can benefit from this analysis. In the long run small code changes are better than simply disabling the error, in case a junior programmer down the line "optimizes" the remedy out.

Altri suggerimenti

I believe removing if (temp != null) will make the warning disappear. FxCop is not smart enough to inspect the conditional execution path I think.

Anyway, I do not see why you come up with this code rather than simply using _bitmapSymbols = new BitmapSymbols(source, sizeSymbols);?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top