Where did variable = null as “object destroying” come from?

Question

Working on a number of legacy systems written in various versions of .NET, across many different companies, I keep finding examples of the following pattern:

pub         


        

Answer 1

I can see it coming from either a misunderstanding of how the garbage collection works, or an effort to force the GC to kick in immediately - perhaps because the objects foo and bar are quite large.

Answer 2

It comes from C/C++ where doing a free()/delete on an already released pointer could result in a crash while releasing a NULL-pointer simply did nothing.

This means that this construct (C++) will cause problems

void foo()
{
  myclass *mc = new myclass(); // lets assume you really need new here
  if (foo == bar)
  {
    delete mc;
  }
  delete mc;
}

while this will work

void foo()
{
  myclass *mc = new myclass(); // lets assume you really need new here
  if (foo == bar)
  {
    delete mc;
    mc = NULL;
  }
  delete mc;
}

Conclusion: IT's totally unneccessary in C#, Java and just about any other garbage-collecting language.

Answer 3

I suspect that this pattern comes from translating C++ code to C# without pausing to understand the differences between C# finalization and C++ finalization. In C++ I often null things out in the destructor, either for debugging purposes (so that you can see in the debugger that the reference is no longer valid) or, rarely, because I want a smart object to be released. (If that's the meaning I'd rather call Release on it and make the meaning of the code crystal-clear to the maintainers.) As you note, this is pretty much senseless in C#.

You see this pattern in VB/VBScript all the time too, for different reasons. I mused a bit about what might cause that here:

http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/122259.aspx

Answer 4

I've seen this in some Java code before. It was used on a static variable to signal that the object should be destroyed.

It probably didn't originate from Java though, as using it for anything other than a static variable would also not make sense in Java.

Answer 5

I think it used to be a common misunderstanding among former C/C++ developers. They knew that the GC will free their memory, but they didn't really understand when and how. Just clean it and carry on :)

Answer 6

It's FUDcargo cult programming (thanks to Daniel Earwicker) by developers who are used to "free" resources, bad GC implementations and bad API.

Some GCs didn't cope well with circular references. To get rid of them, you had to break the cycle "somewhere". Where? Well, if in doubt, then everywhere. Do that for a year and it's moved into your fingertips.

Also setting the field to null gives you the idea of "doing something" because as developers, we always fear "to forget something".

Lastly, we have APIs which must be closed explicitly because there is no real language support to say "close this when I'm done with it" and let the computer figure it out just like with GC. So you have an API where you have to call cleanup code and API where you don't. This sucks and encourages patterns like the above.