title: c# destructors: the dispose "pattern" and best practises
body: <p>I know the difference in meaning and use of destructors and finalisers in c#.</p>
  
  <p>However, typically the answer to a "should I ..." is answered by "don't use destructors, rather use the dispose pattern as shown in <a href="http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx" rel="nofollow noreferrer">MSDN</a>". Eric Lippert <a href="https://stackoverflow.com/questions/7824444/how-can-i-resolve-inexplicable-objectdisposedexceptions-in-my-c-sharp-mvvm-app/7824747#7824747">writes</a> quite <a href="https://stackoverflow.com/questions/4898733/when-should-i-create-a-destructor/4899622#4899622">strongly</a> against using destructors unnecessarily.</p>
  
  <p>But, that "pattern" advocates writing a destructor as such <code>~T() { Dispose(false); }</code>. The stated reason is that it is a "fallback" which is called in case the programmer forgets to call <code>Dispose()</code>. Of course this ignores the fact that finalisers are indeterminate in their operation, and may never even run.</p>
  
  <p>Hence:</p>
  
  <ol>
  <li><p>If I use the dispose pattern, should I also provide the destructor? Incidentally, I am only disposing managed resources (the Entity Framework <code>DataContext</code> for example).</p></li>
  <li><p>If I do provide a destructor: if my class is derived from an <code>IDisposable</code>, 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.</p></li>
  </ol>