c# destructors: the dispose "pattern" and best practises

Question

I know the difference in meaning and use of destructors and finalisers in c#.

However, typically the answer to a "should I ..." is answered by "don't use destructors, rather use the dispose pattern as shown in MSDN". Eric Lippert writes quite strongly against using destructors unnecessarily.

But, that "pattern" advocates writing a destructor as such ~T() { Dispose(false); }. The stated reason is that it is a "fallback" which is called in case the programmer forgets to call Dispose(). Of course this ignores the fact that finalisers are indeterminate in their operation, and may never even run.

Hence:

1. If I use the dispose pattern, should I also provide the destructor? Incidentally, I am only disposing managed resources (the Entity Framework DataContext for example).

2. If I do provide a destructor: if my class is derived from an IDisposable, which may already provide a destructor, then should I provide one too? I thought that one never writes a destructor in such a case, however docs say that it will call the base class' destructor automatically anyway.

Answer 1

I won't actually answer your two questions, but I will provide an opinion on:

The stated reason is that it is a "fallback" which is called in case the programmer forgets to call Dispose().

If it is a requirement that a caller of a method pass, say, a non-null string, then you are perfectly within your rights to throw an exception if they pass null, right? The caller violated the contract; that's exceptional behaviour so you throw an exception. You don't think, oh, the caller "forgot" to pass a valid argument, I think I'll accept the bad input and soldier on. Doing so is effectively changing the contract of the method from "null is unacceptable and will produce an exception" to "null is acceptable and is treated as an empty string", for example.

If it is a requirement that the user calls Dispose when they are done, and they did not, then that's no different than a caller failing to fulfill the contract when calling a method. The caller failed to fulfill a requirement, so crash their program. Have the destructor throw an informative exception if it encounters a non-disposed object. Just as callers quickly learn that passing bad arguments to a method hurts, they'll learn that failing to dispose your object hurts too.

Either explicitly disposing the object is necessary or it is not. If it is necessary, then make sure the user does so. Doing otherwise is concealing their bug.

Answer 2

If I use the dispose pattern, should I also provide the destructor? Incidentally, I am only disposing managed resources (the Entity Framework DataContext for example).

In this case, no. The reason is that, by the time your class is caught by the GC, all of those objects are also going to be handled by the GC. There is no reason to add the overhead of a destructor in this case.

This is part of the complexity of IDisposable - there really should be more than the standard implementation, depending on the usage. In this case, you're encapsulating a resource that implements IDisposable. As such, its important to allow your user to (indirectly) dispose those resources, but you don't need to handle the destructor, as there is no unmanaged resource you directly "own". I cover this in Part 3 of my series on IDisposable if you want more details.

---

if I do provide a destructor: if my class is derived from an IDisposable, which may already provide a destructor, then should I provide one too? I thought that one never writes a destructor in such a case, however docs say that it will call the base class' destructor automatically anyway.

In this case, the base class should expose a protected method of the form protected virtual void Dispose(bool disposing). You would put your resource cleanup logic there, as the base class destructor handles the call to this method for you. For details, see Part 2 of my series on IDisposable.

Answer 3

If you're writing a class, you can't force everyone that uses that class to follow the expected IDisposable pattern. That's why you need the destructor fallback.

Even if "everyone" is "just you", you are human and will sometimes make mistakes.

Answer 4

It's very hard to add something to this question that hasn't been touched already by the great answers here.

I'll try then to give an alternative to the dispose pattern that's advocated on MSDN. I never really liked that Dispose(bool) method, so I think this pattern is better if you definitely need a destructor:

public class BetterDisposableClass : IDisposable {

  public void Dispose() {
    CleanUpManagedResources();
    CleanUpNativeResources();
    GC.SuppressFinalize(this);
  }

  protected virtual void CleanUpManagedResources() { 
    // ...
  }
  protected virtual void CleanUpNativeResources() {
    // ...
  }

  ~BetterDisposableClass() {
    CleanUpNativeResources();
  }

}

But, since you already found out that you really don't need one, your pattern is much simpler:

public class ManagedDisposable : IDisposable {

  // ...

  public virtual void Dispose() {
    _otherDisposable.Dispose();
  }

  IDisposable _otherDisposable;

}

Answer 5

 Or if you know that your object that you are trying to dispose of Implements IDisposable
why not do something like this

StreamWriter streamWrt = null
try
{
streamWrt = new StreamWrite();
... do some code here
}
catch (Exception ex)
{
 Console.WriteLine(ex.Message)
}
Finally
{
  if (streamWrt != null)
  {
    ((IDisposable)streamWrt).Dispose();
  }
}