Setting an object to null within itself

Question

Just wondering if this would be an acceptable way of terminating an object from within itself? Since

this = null;

is not possible. I usually just set a bool called disposed or something and throw an exception if the object is accessed after I terminate it. But then this occurred to me and I thought it might be a cleaner solution but it seems a bit hacky so I wanted a second opinion. Should I stick with setting a bool or go with this. This would also allow the garbage collector to clean up my object too.

public class A
{
    public A()
    {

    }

    public void Method()
    {
        try
        {
            //Do Something.
        }
        catch
        {
            //If it fails destroy the object
            Destroy(this);
        }
    }

    private static void Destroy(A a)
    {
        a = null;
    }
}

One does not "set an object to null", rather one assigns null to a *variable* (or other mutable storage location) that may have previously been non-null .. this in turn may make the previously named object no longer strongly reachable. — , Jul 23 '12 at 01:35

score 7 · Accepted Answer · edited May 23 '17 at 12:27

7

a is a copy of a reference. Set it to null all you like, it's not going to affect the original reference. Now of course you could change the method signature to take it's argument by ref, but why do you want to do this anyway? I can't imagine what problem you are trying to solve here.

This would also allow the garbage collector to clean up my object too.

The GC doesn't need you to set references to null, you're not accomplishing anything with this idea. You're mucking with copies of references; the object is still in memory, and the GC is smart enough to know if a given reference is valid, regardless of whether or not its current value is null.

Please see this SO thread for more details on that.

edited May 23 '17 at 12:27

Community

1
1

answered Jul 23 '12 at 00:39

Ed S.

122,712
22
185
265

Oh awesome. I thought the garbage collector only cleaned up null objects. Thanks! – Axis Jul 23 '12 at 00:45
@Axis: That would be little (no?) better than manual allocation and deallocation ;) – Ed S. Jul 23 '12 at 00:46
@Axis you shouldn't have to worry about the GC at all under most circumstances. For the most part everything "just works". The only times you really need to think about this, are when you register a handler from an event on a long-life object to a handler in a short-life object. – Jonathon Reinhart Jul 23 '12 at 01:12

score 2 · Answer 2 · answered Jul 23 '12 at 00:45

If you want explicit, deterministic destruction, implement interface IDisposable and call Dispose when done with the object. Otherwise, the garbage collector will destroy the object as soon as the last reference goes out of scope. nulling one particular ref won't trigger the collection. Don't second guess the garbage collector unless you know for sure you have to.

What is there in your object that you're so keen to have it destroyed ASAP? The resources that you absolutely cannot afford to hold for longer than necessary are few and far in between - database connections, sockets, memory chunks of a few hundred MB. For those, IDisposable exists. The rest of the objects would live for a few milliseconds before the GC gets to them; such is life in the garbage-collected world. In year 2012, this is considered an acceptable tradeoff.

Setting an object to null within itself

2 Answers2