Is there any reason to set an object to null in the finally block? [duplicate]

Question

I'm cleaning up some C# code for my company and one thing I've been noticing is that the contractors that built this application keep setting object references to null.

Example:

get {
  Object o = new Object(); // create a new object that is accessed by the reference 'o'
  try {
   // Do something with the object
  }
  finally {
    o = null; // set the reference to null
  }
}

From what I understand, the object created still exists. There is a chance it can't be accessed now depending if there are any other references to it, but it will still exist until the GC comes and cleans it up.

Is there any reason to have this in a finally block? Are there any cases where this could possibly create an in-adverted memory leak?

Thanks!

Answer 1

This is dependent on scope.

In your given example, o is only defined within the scope of the property. So it will be useless. However, say o was within the scope of the class. Then it MIGHT make sense to denote the state of o.

As it is currently, it is NOT needed.

Answer 2

If the intent is to have GC collect the object asap, then it's utterly useless.

If the object referenced by o is not used anywhere after the try block, it will be elected for collection immediately after it is last used (i.e., before the variable o goes out of scope, and before it reaches the finally block).

On a related note, see Lippert's Construction Destruction.