Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Strictly speaking, any object that implements <code>IDisposable</code> and whose scope is limited to that function should be within a <code>using</code> block. The <code>IDisposable</code> interface exists to allow classes that deal with unmanaged resources (database connections, file handles, window handles, etc.) to dispose of these resources in a timely, deterministic fashion.</p> <p>There are, in general, three ways in which an <code>IDisposable</code> object is used within a class:</p> <ol> <li>The object is both created and no longer needed within the scope of a single method call. This is quite common, and is when <code>using</code> can (and should) be used.</li> <li>The object is created by the class (or is passed to the class), and its lifetime extends beyond the scope of a single method call but not beyond the life of the class. For example, your class creates a <code>Stream</code> and needs to use it over the lifetime of the object. In this case, your class should implement <code>IDisposable</code> itself and dispose of the object(s) that you own when your own <code>Dispose</code> method is called. An example of this would be something like <code>System.IO.StreamWriter</code></li> <li>The object is passed to the class, but the class doesn't "own" it. This means that the <code>IDisposable</code> object's usable lifetime is beyond the scope of a single method call, and may be beyond the lifetime of your object. In this case, someone else must be responsible for calling <code>Dispose</code>.</li> </ol> <p>The first case is the most common that you'll encounter, which is why the <code>using</code> block exists. It takes care of ensuring that the object will be disposed of, even in the case of an exception.</p> <p>Some examples:</p> <ul> <li>Stream classes</li> <li>Database connections/commands</li> <li>Controls</li> </ul> <p>There's no exhaustive list of classes that implement <code>IDisposable</code>, as that list would be fairly large and filled with classes that you'll likely never encounter. Think about what the class <em>does</em>; does it open some sort of connection or file that needs to be closed? In general, <em>does it acquire some kind of resource that needs to be released</em>? If so, it probably implements it. At a basic level, if the compiler allows you to enclose it in <code>using</code>, then it implements <code>IDisposable</code>.</p> <p>As to the consequences of <em>not</em> calling <code>Dispose</code>, don't consider it. <strong>Call Dispose</strong>. True, the defensive standard is that if your class uses unmanaged resources <em>directly</em>, then you should define a finalizer that will call dispose in the event that your object is collected and someone has failed to call it, but that should not be a design choice. Ever, as far as I'm aware.</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