views:

161

answers:

5

When an exception is thrown or encountered:

void ThrowException()
{
    try
    {
        throw new Exception("Error");
    }
    catch
    {
    }
}

is it & how is it disposed from memory?

and how does the above code differ from the below code in respect of the disposal from memory of the Exception object?

void ThrowException()
{
    try
    {
        throw new Exception("Error");
    }
    catch(Exception e)
    {
    }
}
+7  A: 

Exception does not inherit from IDisposable so it does not need to be disposed. Memory deallocation is done by the GC like for all .NET objects.

rstevens
+2  A: 

The Exception instance simply acts as another object in memory - after the catch method, there aren't any remaining references to the instance, so it will get removed in the next garbage collection sweep.

Exceptions generally don't inherit from IDisposable, as there shouldn't really be external resources associated with an Exception. If you do. have an IDisposable exception, you should look really hard at whether your architecture & code design is correct.

thecoop
+1  A: 

The Exception class will be garbage collected when there are no longer any references to it and the garbage collector eventually takes a turn. An exception object is handled like any other object allocated on the heap.

Since an exception object is bubbled upward, it will no longer have a reference to it when there are no longer methods that catch or throw it higher up the stack.

Both examples will have the same affect since neither of them throw the exception up higher, it will go out of reference when the method returns.

j0rd4n
+2  A: 

Short Answer. Don't worry about it, the garbage collector does it.

Long answer. "Forget" everything you ever knew about memory management and read Top 20 . net garbage collection articles

Binary Worrier
+1  A: 

Since Exceptions don't implement IDisposable they're automatically deleted by the garbage collector like any other object when they aren't referenced any more, so you don't have to care about them. Just implement an example class:

class CustomException : Exception {
    ~CustomException() {
        Console.WriteLine("Exception removed");
    }
}

class Program {
    static void Throw() {
        throw new CustomException();
    }
    static void Main(string[] args) {
        try {
            Throw();
        }
        catch {

        }
    }
}
Dario
Dario: Reading "Since Exceptions don't implement IDisposable they're automatically deleted by the garbage collector" could give the impression that objects that implement IDisposable ARE NOT automatically collected, which we both know is false, maybe expand that if it did implement IDisposable it would (possibly) take longer collect? Or possibly better, remove the mention of IDisposable?
Binary Worrier
@Binary Worrier, Why would it (possibly) take longer to collect an object that implements IDisposable?
LukeH
Because it will have a finaliser. The GC (in theory) puts objects to be collected into two lists, those with finalisers and those without. Those without it can collect immediately, those with one it needs to call the finalisers before they can be collected. This is why it's good practise to put GC.SuppressFinalize(this) in Dispose methods, so the object can be GC'd faster. If this isn't exactly right can my fellow pedants please add a comment and let me know? Thanks :)
Binary Worrier
@Binary Worrier, IDisposable objects don't need to have a finaliser, although in practice they often do (to catch the situation where Dispose wasn't called). So, strictly speaking, the "take longer to collect" caveat applies to objects with finalisers, not IDisposable objects.
LukeH
Luke: You are correct. I had it in my head that the default implementation of IDisposable given by VS included a finaliser . . . don't know where that one came from . . . blatantly ridiculous when you think about it . . . stupid brain . . . mutter mutter mutter
Binary Worrier
Luke - I agree why do we have to think about GS.domydirtywork. Its no rocket science!
divinci