By delete

2011-02-04 13:55:31 8 Comments

For example:

public class Person
    public Person()


When should I manually create a destructor? When have you needed to create a destructor?


@Eric Lippert 2011-02-04 15:20:26

UPDATE: This question was the subject of my blog in May of 2015. Thanks for the great question! See the blog for a long list of falsehoods that people commonly believe about finalization.

When should I manually create a destructor?

Almost never.

Typically one only creates a destructor when your class is holding on to some expensive unmanaged resource that must be cleaned up when the object goes away. It is better to use the disposable pattern to ensure that the resource is cleaned up. A destructor is then essentially an assurance that if the consumer of your object forgets to dispose it, the resource still gets cleaned up eventually. (Maybe.)

If you make a destructor be extremely careful and understand how the garbage collector works. Destructors are really weird:

  • They don't run on your thread; they run on their own thread. Don't cause deadlocks!
  • An unhandled exception thrown from a destructor is bad news. It's on its own thread; who is going to catch it?
  • A destructor may be called on an object after the constructor starts but before the constructor finishes. A properly written destructor will not rely on invariants established in the constructor.
  • A destructor can "resurrect" an object, making a dead object alive again. That's really weird. Don't do it.
  • A destructor might never run; you can't rely on the object ever being scheduled for finalization. It probably will be, but that's not a guarantee.

Almost nothing that is normally true is true in a destructor. Be really, really careful. Writing a correct destructor is very difficult.

When have you needed to create a destructor?

When testing the part of the compiler that handles destructors. I've never needed to do so in production code. I seldom write objects that manipulate unmanaged resources.

@configurator 2011-03-31 04:22:55

"A destructor may be called on an object after the constructor starts but before the constructor finishes." But I can rely on field initializers to have run, right?

@Eric Lippert 2011-03-31 14:11:24

@configurator: Nope. Suppose the third field initializer of an object with a finalizer called a static method which caused an exception to be thrown. When would the fourth field initializer run? Never. But the object is still allocated and must be finalized. Heck, you don't even have a guarantee that fields of type double were fully initialized when the dtor runs. There could have been a thread abort halfway through writing the double and now the finalizer has to deal with a half-initialized half-zero double.

@Mark Mullin 2012-02-12 18:06:19

Excellent post, but should have said "should be created when your class is holding onto some expensive unmanaged object or causes large numbers of unmanaged objects to exist" - For a concrete example, I have a matrix class in C# that utilizes an underlying native C++ matrix class to do a lot of heavy lifting - I make a lot of matrices - a "destructor" is far superior to IDisposable in this specific case, because it keeps the managed and unmanaged sides of the house in better sync

@denfromufa 2015-08-26 19:52:15

pythonnet uses destructor to release GIL in unmanaged CPython

@call-me 2016-05-20 16:31:17

Respect the dead, even in programming.

@Ken Palmer 2016-08-11 18:10:03

Awesome article Eric. Props for this --> "Extra bonus fun: the runtime uses less aggressive code generation and less aggressive garbage collection when running the program in the debugger, because it is a bad debugging experience to have objects that you are debugging suddenly disappear even though the variable referring to the object is in scope. That means that if you have a bug where an object is being finalized too early, you probably cannot reproduce that bug in the debugger!"

@MrPaulch 2016-10-07 15:28:12

@KenPalmer Yes the behaviour described in that paragraph hit me hard. Have been looking for the source of an AccessViolationException for ages now. Of course it occured only in the Release build. And of course it occoured some place else (Namely in the Read method of an UnmanagedMemoryStream) And of course I had forgotten the Article about how dangerous Finalizers are. Finally someone in the office suggested to put some kind of output into the Finalizer of every unmanaged object to track their existence. Needless to say, some of them got destroyed "early".

@octopusgrabbus 2017-07-27 17:08:32

@EricLippert I've referenced you in a new post asking a question about C# finalizers.

@Neil.Allen 2013-10-22 19:12:46

I have used a destructor (for debug purposes only) to see if an object was being purged from memory in the scope of a WPF application. I was unsure if garbage collection was truly purging the object from memory, and this was a good way to verify.

@John Saunders 2011-02-04 13:58:05

You don't need one unless your class maintains unmanaged resources like Windows file handles.

@David Heffernan 2011-02-04 14:01:53

Well, actually, it's called a destructor

@delete 2011-02-04 14:01:59

Now I'm confused. Is it finalizer or destructor?

@Ani 2011-02-04 14:03:52

The C# spec does in fact call it a destructor. Some see this as a mistake.…

@HasaniH 2011-02-04 14:05:54

It's actually called a Destructor and it implicitly calls the Finalize method:

@JDB still remembers Monica 2012-11-13 22:07:55

@ThomasEding - Yes it is. C# uses destructor syntax, but it's actually creating a finalizer.

@Benjol 2015-12-03 07:07:33

I love the comments here, real panto :)

@HasaniH 2011-02-04 14:08:45

Destructors provide an implicit way of freeing unmanaged resources encapsulated in your class, they get called when the GC gets around to it and they implicitly call the Finalize method of the base class. If you're using a lot of unmanaged resources it is better to provide an explicit way of freeing those resources via the IDisposable interface. See the C# programming guide:

@Nicole Calinoiu 2011-02-04 14:01:22

It's called a "finalizer", and you should usually only create one for a class whose state (i.e.: fields) include unmanaged resources (i.e.: pointers to handles retrieved via p/invoke calls). However, in .NET 2.0 and later, there's actually a better way to deal with clean-up of unmanaged resources: SafeHandle. Given this, you should pretty much never need to write a finalizer again.

@JDB still remembers Monica 2012-11-13 22:04:48

@ThomasEding - Yes it is. C# uses destructor syntax, but it's actually creating a finalizer. Again.

@supercat 2019-04-16 18:28:52

@JDB: The linguistic construct is called a destructor. I dislike the name, but that's what it's called. The act of declaring a destructor causes the compiler to generate a finalizer method which contains a little bit of wrapper code along with whatever appears in the body of the destructor.

@Vlad Bezden 2011-02-04 13:59:48

When you have unmanaged resources and you need to make sure they will be cleaned up when your object goes away. Good example would be COM objects or File Handlers.

@Øyvind Bråthen 2011-02-04 13:58:05

It's called a destructor/finalizer, and is usually created when implementing the Disposed pattern.

It's a fallback solution when the user of your class forgets to call Dispose, to make sure that (eventually) your resources gets released, but you do not have any guarantee as to when the destructor is called.

In this Stack Overflow question, the accepted answer correctly shows how to implement the dispose pattern. This is only needed if your class contain any unhandeled resources that the garbage collector does not manage to clean up itself.

A good practice is to not implement a finalizer without also giving the user of the class the possibility to manually Disposing the object to free the resources right away.

@TomTom 2011-02-04 14:00:43

Actually it is NOT called a destructor in C# with good reason.

@Øyvind Bråthen 2011-02-04 14:03:55

Actually it is. Thanks for giving me a downvote because you are mistaken. See the MSDN library regarding this specific issue:

@David Heffernan 2011-02-04 14:06:00

@TomTom it's official name is destructor

@HasaniH 2011-02-04 14:12:31

Its actually not a fallback method, it simply allows the GC to manage when your objects free unmanaged resources, implementing IDisposable allows you to manage that yourself.

Related Questions

Sponsored Content

17 Answered Questions

[SOLVED] 'Static readonly' vs. 'const'

  • 2009-04-16 11:21:43
  • Svish
  • 382084 View
  • 1392 Score
  • 17 Answer
  • Tags:   c# constants

48 Answered Questions

[SOLVED] Deep cloning objects

  • 2008-09-17 00:06:27
  • NakedBrunch
  • 814444 View
  • 2244 Score
  • 48 Answer
  • Tags:   c# .net clone

28 Answered Questions

[SOLVED] When should I use a struct rather than a class in C#?

  • 2009-02-06 17:37:55
  • Alex Baranosky
  • 274787 View
  • 1401 Score
  • 28 Answer
  • Tags:   c# struct

20 Answered Questions

[SOLVED] How to Sort a List<T> by a property in the object

21 Answered Questions

[SOLVED] Is there a destructor for Java?

27 Answered Questions

[SOLVED] Why not inherit from List<T>?

28 Answered Questions

[SOLVED] Catch multiple exceptions at once?

7 Answered Questions

[SOLVED] Do I need to explicitly call the base virtual destructor?

  • 2009-03-24 14:22:10
  • Nick Bolton
  • 136931 View
  • 352 Score
  • 7 Answer
  • Tags:   c++ destructor

11 Answered Questions

[SOLVED] Should 'using' directives be inside or outside the namespace?

Sponsored Content