locked
Explicity Destroying Objects RRS feed

  • Question

  • User865450124 posted

    Having come from the world of VBA, I live, eat and breathe the gospel truth "...to close what you open and destory what you create." I realize that ASP.NET has garbage collection, but is there an explicit need to destroy objects as you create them? I was looking as some code-behind and realized that since I'm working with a lot of objects within a FormView that I've got a ton of DIM statements used to grab objects via .FindControl.

    Wednesday, December 16, 2009 9:14 PM

Answers

  • User397347636 posted

    Unlike VBA (or VB6), there is no need to explicitly set any local variables to 'Nothing' - when they go out of scope the GC will know that they can be collected if there are no other references to the object - setting to 'Nothing' would just tell the GC the same thing, so there's no need. 

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, December 19, 2009 8:26 PM

All replies

  • User-573138384 posted

    You are in correct path. Me too think of dispose when I do code. But, in .Net, we have a wonderful feature of GarbageCollection, which will be taken care by CLR, the runtime env. So if you are worrying about dim statements or the objects of your classes, you need not worry. Once the variables go out of scope, I mean once it is unreferenced, GC will call finalize method any time to destroy the object. You can explicitely call GC.Collect. But dont do it. If you are working with any external objects, COM or IO (file read/write) or any third party components, then you have to use Close and  Dispose methods. One more thing is if you have a class for data access and you have Connection, Command objcets, then you the class can be inherited form IDisposable interface, just for Dispose method and there you can make objects null or can close connection. Here also we solely worryng about open connections but not memory...

    Ther are good practices like creating objcets for that scope by using 'using' statement...

    You can refer this for using

    Wednesday, December 16, 2009 10:26 PM
  • User-319574463 posted

    I suggest that you run FXCOP on your Dot Net EXE or DLL to check for missing dispose calls. You can get FXCOP from FXCOP 1.36 http://www.microsoft.com/downloads/details.aspx?FamilyID=9aeaa970-f281-4fb0-aba1-d59d7ed09772&DisplayLang=en

    Saturday, December 19, 2009 12:53 PM
  • User865450124 posted

    Its actually an ASP.NET application with VB.NET in the code-behind.

    Saturday, December 19, 2009 2:40 PM
  • User-319574463 posted

    Is it a Web Site or a Web Application? If the latter you can run FXCOP on the application.

    Saturday, December 19, 2009 3:01 PM
  • User865450124 posted

    How do are you defining the difference between the two? The project a collection of aspx pages that together operate on a database which, depending with whom your speaking, could be considered an application.


    Saturday, December 19, 2009 3:08 PM
  • User-319574463 posted

    They are distinct types. Whilst some people like the Web Site approach, the web application is far better as the web application is pre-compiled to a DLL. This gives far better diagnostics than a web site project approach.

    Irrespective of project type, the data and business logic should be in a separate DLL which can be checked with FXCOP.

    Saturday, December 19, 2009 3:15 PM
  • User865450124 posted

    They are distinct types. Whilst some people like the Web Site approach, the web application is far better as the web application is pre-compiled to a DLL. This gives far better diagnostics than a web site project approach.

    Irrespective of project type, the data and business logic should be in a separate DLL which can be checked with FXCOP.

    So if I'm going with a Web Site approach, obviously FXcop is irrelevant since there aren't any DLL's. But going back to the original questions, should I only be concerned with explicity closing what I open and not worry about explicity destroying an objects that I create such as...


    .
    .
    .
    Dim LabelTest as Label = CType(e.findcontrol("TestLabel"),Label)
    .
    .
    .


    Since the statement above is effectively a SET statement, the VBA Law of God would demand that you destroy it as in

    .
    .
    .
    Set ctl = Controls("TestLabel")
    .
    .
    .
    Set ctl = Nothing
    .
    .
    .



    Saturday, December 19, 2009 3:34 PM
  • User-319574463 posted

    Yes you should close objects and where there is a dispose method on the object, call it.

    Saturday, December 19, 2009 3:42 PM
  • User397347636 posted

    Unlike VBA (or VB6), there is no need to explicitly set any local variables to 'Nothing' - when they go out of scope the GC will know that they can be collected if there are no other references to the object - setting to 'Nothing' would just tell the GC the same thing, so there's no need. 

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, December 19, 2009 8:26 PM
  • User865450124 posted

    Unlike VBA (or VB6), there is no need to explicitly set any local variables to 'Nothing' - when they go out of scope the GC will know that they can be collected if there are no other references to the object - setting to 'Nothing' would just tell the GC the same thing, so there's no need. 


    Thx. That's the answer that I'm looking for.

    Saturday, December 19, 2009 9:32 PM
  • User865450124 posted

    Unlike VBA (or VB6), there is no need to explicitly set any local variables to 'Nothing' - when they go out of scope the GC will know that they can be collected if there are no other references to the object - setting to 'Nothing' would just tell the GC the same thing, so there's no need. 


    Thx. That's the answer that I'm looking for.

    Saturday, December 19, 2009 9:32 PM
  • User-952121411 posted

    I know this thread is solved, and I am coming in late, but I wanted to add my thoughts on this for the original poster.

    While it is true that .NET has the beauty of GarbageCollection, I personally prefer to develop in a more explicit manner and have deterministic object disposal. The purpose of implementing cleanup on objects is for programmers calling a class to have deterministic finalization. Although it is not necessary, it is very advisable to clean resources in a deterministic way since GC is not deterministic.

    Why go the extra step to clean up objects and state .Dispose() or use a 'Using' block?  For one, developers coming in behind you can see the actual scope intended for the objects use.  Ideally, when instantiating an object it should only be alive for as long as needed, and disposed of when not needed anymore.

    A beginners mistake I see all too often is to declare an object at the Page level like below:

    'Declare an instance of 'MyCustomClass' so the entire page can use it
    Private MyObject As New MyCustomClass()

    Ok, the above practice is really bad.  Why?  The scope is so broad that the object will be created even for methods and events that don't need it.  That's sloppy programming.  The object should be declare in a manner, where only used within the scope needed, and disposed of as soon as it is out of scope.  Below are (2) better methods for declaring and disposing of the object above:

    Using MyObject As New MyCustomClass()
        MyObject.DoSomething()
    End Using  'Object will be disposed of here
    
    'or...
    Dim MyObject As New MyCustomClass()
    Try
       MyObject.DoSomething()
    Finally
       'Clean Up
       If MyObject IsNot Nothing Then MyObject.Dispose()
    End Try


    One other note for the code examples I have been giving above, the object created must implement the 'Idisposable' interface on the class for the 'Dispose' method to be accessible.  I will provide some links below about implementing this code (really easy as of VS.NET 2008)

    So one might be arguing, "Why would I go to any of that trouble if the GC will take care of it for me??".  Well let me provide another example since we are speaking of VB.NET.  The following code does work, but it is not good:

    Dim MyString As String = "25"
    Dim MyInteger As Integer = 0
    'Use implicitly conversioning to dump the String Value into the Integer variable
    MyInteger = MyString


    The above code is a bit analogous IMO to using the GC as a way to clean up objects; it is using 'implicit' conversions to cast the string to an integer.  Does it work?  Sure it does.  Is it good programming.  No.  The better method is to explicitly (and even add exception handling) convert the string to an Integer like below.

    Try
       'Attempt to parse the String value into an Integer
       MyInteger = Integer.Parse(MyString)
    Catch ex As Exception
       'Exception handling here
    End Catch
    


    The above code is much better and a more explicit and clearly defined way of coding?  For who?  Most of the time it is for those peers that will becoming in behind you, to have more clarity in how the code flows.  Deterministic object disposal goes along these guidelines, and is a good practice IMO.

    Many of the .NET commonly used objects (like a DataSet for example) already expose a .Dispose() method, so implementing this is quite easy.  If you have written a custom class, no .Dispose will be available on the object by default; as mentioned before you need to implement the 'Idisposable' interface.  In VS.NET 2008, once you type the following and press 'Enter':

    Implements IDisposable

     

    All of the required code will be added to your class.  For more information, read up on the following link:

    IDisposable Interface:

    http://msdn.microsoft.com/en-us/library/system.idisposable.aspx

    Again, nothing noted before is incorrect; you can use the GC.  However, I wanted to add some points about more deterministic object disposal to give you some more information.

    Hope this helps! Smile

    Monday, December 21, 2009 12:24 PM
  • User865450124 posted

    While I get the bit about explicity converting a value within a Try...Catch, in my situation I'm working with an ASP.NET where the DIM is used to grab a control within the markup. If the control isn't found, there's going to be bigger issues than just being unable to cast it. Since there is a specific control that I'm grabbing using .FindControl, the control type is known in advance since it exists on the page to begin with.


    Monday, December 21, 2009 1:29 PM