"CA2000 Dispose objects before losing scope " for unknown reason

Question

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.

@DJKRAZE: Yes, the code compiles and runs just fine, so `temp` implements `IDisposabe`; it is just FxCop complaining, but I am using the same pattern in several other places, and getting the same FxCop warning in just some of them. — Pieter Geerkens, Jun 19 '13 at 22:16
@DJKRAZE: It doesn't matter; I have tried it both ways and get the same warning form FxCop. Can you see a reason why to prefer one over the other? I cannot. — Pieter Geerkens, Jun 19 '13 at 22:21
what if you rewrite the `temp.Dispose` to `((IDisposable)temp).Dispose();` if it complains at compile time then just set the value of temp to `null` and move on — MethodMan, Jun 19 '13 at 22:26
@DJKRAZE: If this turns out to be a known false positive in FxCop, then I move on; until then, I am endeavouring to learn what FxCop thinks is inadequate about the code listed, and how it differs in practice from the example given on the MSDN documentation. — Pieter Geerkens, Jun 19 '13 at 22:32
Why not set the value to null and or let the GC handle it if you are fighting with this issue — MethodMan, Jun 19 '13 at 22:34

Pieter Geerkens · Accepted Answer · 2013-06-21T17:57:42.043

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:

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.

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.

score 0 · Answer 2 · answered Jun 20 '13 at 01:38

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);?

"CA2000 Dispose objects before losing scope " for unknown reason

2 Answers2