Is there a reason why objects should be set to null after use?

Question

I see a lot of code where the objects are set to null in the finally section or at the end of a method, for example:

        [WebMethod]
        [ScriptMethod(ResponseFormat = ResponseFormat.Json)]
        public void buildUpdates(int batchId, string mkt)
        {
            aplUpdate oDU;
            DataSet ds;
            DataTable dtTbls;
            DataTable dtData;
            List<dbVer> resp;

            try
            { 
                oDU = new WEB_APL.APL.aplUpdate(MyWeb.Properties.Settings.Default.DBCon);

                ds = new DataSet(); 
                ds.DataSetName = batchId.ToString();
                dtTbls = oDU.getDetails(true);
                resp=GetDBVersions();

                foreach (DataRow dr in dtTbls.Rows)
                {
                    .....              
                }
                ds.WriteXml(HttpContext.Current.Server.MapPath("~") + "\\" + ds.DataSetName + ".xml", XmlWriteMode.WriteSchema);

            }
            catch (Exception ex)
            {
                throw ex;
            }
            finally
            {
               oDU = null;
               ds=null;
               rest=null;
               dtTbls=null;
               dtData=null;
            }
        }

I think this is unnessesary since expired objects will be handled automatically by the .NET garbage collector.

Is there a reason why one should reset to null?

possible duplicate of [Do you need to dispose of objects and set them to null?](http://stackoverflow.com/questions/2926869/do-you-need-to-dispose-of-objects-and-set-them-to-null) or [Setting Objects to Null/Nothing after use in .NET](http://stackoverflow.com/questions/2785/setting-objects-to-null-nothing-after-use-in-net) — Tim Schmelter, Mar 12 '14 at 08:38

score 2 · Accepted Answer · answered Mar 12 '14 at 08:38

Actually it is not handled automatically.

The issue being that as long as for example oDU is referenced, it can not be collected. Which means that basically if your holding object is not collected then references can not be collected. GOod style is to clear references when you do not need them anymore. At least for class / struct level variables.

Now, in this particular case it is totally not needed. The GC has nothing to do with this.

What has to do with this is that all these variables are local to the method, so they go out of scope anyway at the end of the method (and in runtime earlier, once they fall out of scope).

As such it is simply totally redundant.

So once they are out of scope they will be cleaned up by the GC when it feels to do so? — Atomic Star, Mar 12 '14 at 09:00
Yes. As they are not referenced at all the GC will collect them - eventually. Core here is "when it feels to do so". — TomTom, Mar 12 '14 at 09:03

score 1 · Answer 2 · answered Mar 12 '14 at 08:38

1

If they are local variables, no, it does not make sense. It's probably a legacy habit.

If they are class level variables, it might make sense. Depends on the use.

Edit:

        catch (Exception ex)
        {
            throw ex;
        }

This however is a faux-pas. This will cripple the stacktrace. If you don't want to handle an exception, don't use a catch block or use the throw keyword without the variable so the stacktrace is kept intact.

        catch (Exception ex)
        {
            throw;
        }

answered Mar 12 '14 at 08:38

nvoigt

75,013
26
93
142

Thanks for noting that throw ex. – Atomic Star Mar 12 '14 at 09:03
Hey @nvoigt If you enjoy doing such style suggestions and similar, how about you give [codereview.se] a visit? I'm sure you'll like it :) – Vogel612 May 08 '14 at 17:09

Vogel612 · Answer 3 · 2014-03-12T08:51:24.023

1

This is probably intended to prevent memory leaks and unneeded resource locks on things like:

Database Connections
Files
Streams
Generally Lockable and Disposable Objects

THIS DOES NOT WORK
Setting Objects (especially connections and streams) to null does not cleanly dispose/close them, in fact it's totally useless noise in your code.

you should instead use using statements, similar to the following example:

using (IDisposable thingy = new FileStream("filepath/connection/whatever"){
   //do something with thingy
}

edited Mar 12 '14 at 08:51

answered Mar 12 '14 at 08:40

Vogel612

5,620
5
48
73

2

Just that it does not prevent them. It's simply superfluous. Using-blocks would indeed help, setting it to null is... dead code. – nvoigt Mar 12 '14 at 08:41

Is there a reason why objects should be set to null after use?

3 Answers3