C# compiler option to find classes that implement IDisposable

[Carl Johansson]

Being quite new to C#, I may have misunderstood this. If so please bear with
me!

As far as I can understand, any instances of a class that implements the
IDisposable interface must call the Dispose method not create leaks of
resources!? This can be accomplished by explicitly calling Dispose or
through the "using" statement.

For example, a recursive method that creates hundreds or thousands of
instances of, for example, OleDbConnection , OleDbCommand, and
OleDbDataReader , would eventually cause havoc unless they were explicitly
disposed through the Dispose method or the using statement, right?

Now, if all of the above is true, what is the easiest way to identify all
classes the implement the IDisposable interface? The "Auto list members"
pop-up window i VS will show the Dispose method if it is present, but then I
must always be alert, and that, I am not! Is it possible to get the C#
compiler to generate warning messages about these classes when used?

Best Regards Carl Johansson

[Jon Skeet [C# MVP]]

On Sep 24, 11:32 am, "Carl Johansson"
<carl.johans... @nogarbagehalld e.comwrote:

Being quite new to C#, I may have misunderstood this. If so please bear with
me!

As far as I can understand, any instances of a class that implements the
IDisposable interface must call the Dispose method not create leaks of
resources!? This can be accomplished by explicitly calling Dispose or
through the "using" statement.

No, the instances don't call Dispose - the *clients* of those classes
call Dispose.
That doesn't mean it's always cut-and-dried as to where things should
be disposed. For instance, if you create a Stream and pass it into
Image.FromStrea m, you need to leave the stream open - image will close
it when the image is disposed.

For example, a recursive method that creates hundreds or thousands of
instances of, for example, OleDbConnection , OleDbCommand, and
OleDbDataReader , would eventually cause havoc unless they were explicitly
disposed through the Dispose method or the using statement, right?

Yes.

Now, if all of the above is true, what is the easiest way to identify all
classes the implement the IDisposable interface? The "Auto list members"
pop-up window i VS will show the Dispose method if it is present, but then I
must always be alert, and that, I am not! Is it possible to get the C#
compiler to generate warning messages about these classes when used?

No - because you don't always want to dispose of something in the same
place you create it.

I'm afraid you basically have to be disciplined about it.

Jon

[james]

Carl,

The objects dispose themselves when they are memory collected.
Nothing tricky... its part of the design pattern. For
OleDbConnection , an ancestor has

~Component()
{
this.Dispose(fa lse);
}

and Dispose is virtual.

You should call Dispose on IDisposables when you are finished because
it might be a while before the memory collector runs, but forgetting
will not cause "havoc".

-James

[Jon Skeet [C# MVP]]

On Sep 24, 1:39 pm, james <james.w...@gma il.comwrote:

The objects dispose themselves when they are memory collected.

You should almost *never* rely on this, however. If something
implements IDisposable, you should call Dispose when you're done with
it.

The finalizer is merely a "belt and braces" approach in case you
forget to explicitly dispose things.

<snip>

You should call Dispose on IDisposables when you are finished because
it might be a while before the memory collector runs, but forgetting
will not cause "havoc".

Um, it could do. If you forget to close connections explicitly, you
could end up running out of connections unnecessarily. Likewise not
disposing of a FileStream could stop you from then reopening the file
for writing.
This is also non-deterministic - so reproducing this issue reliably
could almost impossible.

Personally, I count that as "havoc"...

Jon

[Brian Gideon]

On Sep 24, 7:39 am, james <james.w...@gma il.comwrote:

Carl,

The objects dispose themselves when they are memory collected.
Nothing tricky... its part of the design pattern. For
OleDbConnection , an ancestor has

~Component()
{
this.Dispose(fa lse);

}

and Dispose is virtual.

You should call Dispose on IDisposables when you are finished because
it might be a while before the memory collector runs, but forgetting
will not cause "havoc".

-James

Omitting a call to Dispose could be problematic in scenarios where the
object holds onto a resource in a manner that prevents other objects
from acquiring the same resource. Even though you may be finished
using that resource logically it might not be released until the GC
runs. If you create another instance that attempts to access the same
resource an exception may be thrown.

[james]

Jon,

I was trying to say that for someone just learning C# they don't need
to obsess over finding every IDisposable.

If you use the wizards in Visual Studio you can write an database
application without writing much code, and the worst thing would be to
kludge in calling Dispose everywhere because you aren't sure if the
generated code does that.

-James

[Jon Skeet [C# MVP]]

On Sep 24, 3:13 pm, james <james.w...@gma il.comwrote:

I was trying to say that for someone just learning C# they don't need
to obsess over finding every IDisposable.

Well, I think it's a good idea to be aware of it right from the start,
and try to build up an understanding of what implements IDisposable,
calling it appropriately. Best not to get into bad habits, IMO. I've
seen far too much code which calls Stream.Close() explicitly without
using a finally block etc - if you get into the habit of using a
"using" statement where appropriate, you don't end up with code like
that.

If you use the wizards in Visual Studio you can write an database
application without writing much code, and the worst thing would be to
kludge in calling Dispose everywhere because you aren't sure if the
generated code does that.

Well, that would certainly be bad - but so would saying, "Oh, it's
okay - the finalizer will take care of it."
The latter will lead to hard-to-reproduce bugs.

Jon

[Doug Semler]

"james" <ja********@gma il.comwrote in message
news:11******** *************@r 29g2000hsg.goog legroups.com...

Jon,

I was trying to say that for someone just learning C# they don't need
to obsess over finding every IDisposable.

I disagree. That's like saying that someone just learning C++ doesn't need
to worry about what the "virtual" keyword on a destructor declaration means.
--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

[Brian Gideon]

On Sep 24, 7:52 pm, "Doug Semler" <dougsem...@gma il.comwrote:

"james" <james.w...@gma il.comwrote in message

news:11******** *************@r 29g2000hsg.goog legroups.com...

Jon,

I was trying to say that for someone just learning C# they don't need
to obsess over finding every IDisposable.

I disagree. That's like saying that someone just learning C++ doesn't need
to worry about what the "virtual" keyword on a destructor declaration means.

--

I don't know...I mean since James used the word obsess I can't
disagree too much. Afterall, if you obsessed over *every* little
detail during the learning process you'd almost certainly develop some
negative level of frustration.

[Doug Semler]

"Brian Gideon" <br*********@ya hoo.comwrote in message
news:11******** **************@ d55g2000hsg.goo glegroups.com.. .

On Sep 24, 7:52 pm, "Doug Semler" <dougsem...@gma il.comwrote:

>"james" <james.w...@gma il.comwrote in message

news:11******* **************@ r29g2000hsg.goo glegroups.com.. .

Jon,

I was trying to say that for someone just learning C# they don't need
to obsess over finding every IDisposable.

I disagree. That's like saying that someone just learning C++ doesn't
need
to worry about what the "virtual" keyword on a destructor declaration
means.

--

I don't know...I mean since James used the word obsess I can't
disagree too much. Afterall, if you obsessed over *every* little
detail during the learning process you'd almost certainly develop some
negative level of frustration.

For me, unfortunately (or fortunately??) the words "worry" and "obsess" mean
almost the exact same thing. Psychological thing I guess...

On the other hand, not understanding the various features and semantics of
the language/environment in which you are programming, whether it be the
nuances of IDisposable or virtual destructors or even whether the modulus
operator result is negative depending upon the sign of the dividend or
divisor can be "dangerous" .

--
Doug Semler, MCPD
a.a. #705, BAAWA. EAC Guardian of the Horn of the IPU (pbuhh).
The answer is 42; DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, abbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?