[adn258]

So many times you end up with a class and many times objects that are Idisposible and that need to be disposed like a filebrowser filestream etc. you can just use using( with and this works well and it's what I usually use. What if you DO NOT use using though on these objects and you instead dispose of them in the class destructor method like

~WhateverClass()
{
  TheFileBrower.Dispose();
}

etc. etc. for the objects used in that class. Does this pose any advantage or is it a bad idea? Details? Thanks guys

[Michael26]

The framework automatically disposes the object once the reference to that object is gone, and there is also try-finally block that is useful for cleaning up any resources that are allocated in the try block.

[lucky3]

Here is a recent topic about disposing objects.

[[email protected]]

I consider that to be a very bad idea. A few potential problems with that include:

1) Garbage collection, and therefore finalization, is nondeterministic, i.e. you cannot really predict when it will happen (in reality, it's not safe to assume that either will ever happen). This means that by relying on a finalizer, you will likely be holding onto the resource that requires clean up longer than is necessary. This could lead to resource starvation, and resource hogging.

2) Extra memory pressure will be put on your application, as it takes the garbage collector longer to finally get around to cleaning up objects that require finalization. Further, this is transitive, i.e. all objects that the finalizable object references will not be eligible for garbage collection until the finalizable object has been finalized.

3) The actual amount of work the garbage collector has to do during a collection increases when relying on finalizers, causing performance degradation. Plus, it's more expensive to allocate an object that defines a finalizer.

4) Your code could often be pointless. Think about it for a second. If ~WhateverClass() is being called, it means the WhateverClass instance is eligible for garbage collection. From that, we can infer that the TheFileBrowser instance is also eligible for garbage collection. Therefore, TheFileBrowser instance's finalizer could have already been called, thus leaving your call to Dispose() redundant.

5) Leading on from point 5 (and point 1), it's actually not safe to access other finalizable objects from a finalizer, because there is no guarantee which order objects will be finalized in. Therefore, the object you are accessing may have already been finalized, and therefore may be in an inconsistent state.

6) Finalizers in general add extra complexity to a project, as they are difficult to implement correctly, and not every developer may understand them fully. You should really consider what you would gain from adding any sort of extra complexity before you add it. If the gain isn't worth it, forget it. In this case, you actually aren't gaining anything. It's all loss.

Summary

In conclusion, always favor calling Dispose() explicitly over relying on finalizers. Finalizers should not be used as anything other than a fallback mechanism, and should only be used when you need to release unmanaged resources, of which aren't finalized, that your object holds directly. Further, any finalizers you define should be part of a good IDisposable implementation to enable the client to free resources deterministically.


EDIT:

Quote

The framework automatically disposes the object once the reference to that object is gone

You have to be careful with your terminology here. The garbage collector reclaims the memory occupied by your objects when/if necessary. In .NET terminology, it doesn't dispose of them (although, it is true that the garbage collector can call a finalizer, which then turn calls Dispose()). The garbage collector has no knowledge of how to properly close file handles, for example. The garbage collector is merely a memory management technique that sees memory in isolation, with no real context regarding what is represented by a particular block of memory.

Quote

there is also try-finally block that is useful for cleaning up any resources that are allocated in the try block.

Absolutely true. Note though that the using statement mentioned in the OP is just syntactic sugar that gets compiled as a try-finally block, as demonstrated here

This post has been edited by [email protected]: 10 February 2013 - 04:54 AM
Reason for edit:: EDIT 2 - Changed conclusion to make it clearer

[Curtis Rutland]

The MSDN has a few things to say about it too:

http://msdn.microsof...Disposable.aspx

Read the example and see how they use Destructors and Dispose methods. This is their recommended way of doing things.

[adn258]

Good points guys thanks. Yeah that was a pretty dumb question to ask now that I get thinking about it. From my experience and I'd love to here from other people I've never had ANY REASON TO USE THE DESTRUCTOR IN A CLASS YET IN C#.

When and where would you ever actually use this? Maybe to un-reference event handlers using -= ? I've just never had to use it personally.

[[email protected]]

I've never had a reason to use one either. You definitely shouldn't use them to unregister event handlers. That would be pointless, and harmful.

The whole problem with not unregistering event handlers is that, under certain circumstances, the registered handlers will prevent your object from becoming eligible garbage collection when it should be. However, your finalizer will only run if your object is eligible for garbage collection. See the problem?

As I said:

Quote

Finalizers should not be used as anything other than a fallback mechanism, and should only be used when you need to release unmanaged resources, of which aren't finalized, that your object holds directly. Further, any finalizers you define should be part of a good IDisposable implementation to enable the client to free resources deterministically.

An example of a good use for a finalizer is in the link Curtis Rutland posted. However, with the introduction of the SafeHandle type in .NET 2.0, you will very rarely, if ever, need to define your own finalizer.