Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Basically, you only need to implement the full <code>~Destructor()</code> pattern with dispose if you have a class that has unmanaged fields or properties. </p> <p>If all of your fields and properties are managed and not disposable, then you do not need to implement IDisposable at all. </p> <p>If one of your fields or properties are disposable, then you need to just implement the IDisposable pattern. You don't necessarily have to go the whole hog with the above pattern.</p> <p>If in the last case you do have an unmanaged resource in a field or property (e.g. a native pointer to something, a database connection other than ADO or other managed connections) then .net has no idea how to clean it up when the garbage collector rolls around.</p> <p>In this case, you need to consider two places where your object will be cleaned up. Either it will be cleaned up by the developer calling <code>Dispose()</code> like he should, or he'll forget. If he forgets, and you have a destructor, then it's put on a finalization queue. </p> <p>This is where the <code>Dispose(disposing)</code> call comes in. If the developer is good and calls <code>Dispose()</code>, then you send in true so that the managed resources can be cleaned up as well. </p> <p>If the developer has not called dispose and the poor object ends up on the finalization queue, then calling <code>Dispose()</code> on the managed objects will throw an exception because they don't exist anymore. So in this case you send in a False, so that the managed resources are skipped and avoid the exception. I'm not sure about this, but legends say that throwing an exception on the finalization queue quits the whole process and could even end the world. So don't do it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload