Reputation: 159
I have some files written to a temp location in c#. They are then rendered as pdf thumbnails. When the object is destroyed i want the location cleaned up so is it ok in this instance to use a deconstructor?
~Foo()
{
try
{
Directory.Delete(path, true);
}
catch (IOException ex)
{
Console.WriteLine("exception: " + ex.Message + " . from: Foo_Closing");
}
Upvotes: 2
Views: 568
Reputation: 30520
Implement the IDisposable Interface istead:
public class tester : IDisposable
{
#region IDisposable Members
public void Dispose()
{
//cleanup code here
}
#endregion
}
using (tester t = new tester())
{
}
//tester now disposed
But don't forget this gem of knowledge from MSDN:
Because the Dispose method must be called explicitly, objects that implement IDisposable must also implement a finalizer to handle freeing resources when Dispose is not called
So, you should also implement you finalizer as well as your IDisposable interface, bearing in mind that both will be called.
Upvotes: 2
Reputation: 19608
There is an option to delete temp files on close, if you are able to leverage that it doesn't matter right? Try these links
Upvotes: 0
Reputation: 160992
Even though it has the same syntax as a C++ destructor this a finalizer in C# which runs when the object is garbage collected at finalization - this will have a performance impact since the GC has to run a separate thread to run all finalizers, to do this your object instance will live longer than neccessary.
Having said that you should not use it if you do not absolutely have to - an exception is when you have to dispose of resources, in which case your class should also implement IDisposable
. This would allow consumers of your class to wrap it in a using
block, which will call Dispose()
- that is where you should tear down resources.
Upvotes: 7
Reputation: 3777
why not use IDisposable inteface instead and then you can wrap your call with "using" and Dispose() will perform all the clean up it needs to perform
public class Foo : IDisposable
{
public void Dispose() { //Clean up here}
}
using (foo = new Foo() ) { //consume foo here }
Upvotes: 1
Reputation: 7973
Avoid implementing finalzers of at all possible. You don't control when they get called, and they cause performance loss as the runtime needs to treat objects with finalizers specially. In general, you should only implement a finalizer if you have a native object handle or other native resource that needs to be cleaned up.
Instead, implement the IDisposable interface on your class, move your cleanup code to the Dispose method, and make sure all your clients call the Dispose method (the using
statement is handy for this purpose).
Upvotes: 2
Reputation: 42363
I'd probably just use the environment's temporary file/folder locations so that the files can be cleaned up by a user or administrator as part of the normal housekeeping process.
Don't bother doing this as it smacks of a hack - is it really that important that the folders are deleted there and then?
Upvotes: 2
Reputation: 292675
The problem with deconstructors (aka destructors or finalizers) is that you can't predict when they will run, since they are called by the garbage collector. In order to have a predictable behavior, you should implement IDisposable
and call Dispose
explicitly (or use the object in a using
block)
You can also call Dispose
from the destructor in case it was not called explicitly. See this page for the recommended pattern to use.
Upvotes: 3
Reputation: 1824
You should implement the IDisposable interface, and do your cleanup in there.
Upvotes: 3