469,898 Members | 2,101 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

Rule of Thumb for a Protected Dispose() Method?

Greetings all,

I'm wondering if there's a rule of thumb related to objects that
implement IDisposable, but whose Dispose() methods are actually marked
as protected. If you dig around System.IO, you'll see a lot of these,
like StreamReader, StreamWriter, etc. Is it still a best practice to
wrap those objects in a using block?

All of the MSDN docs DO wrap such objects in a using block, but I'm
wondering if that actually accomplishes anything. Also, does anyone
know why the Dispose method is marked as protected on such objects?
Thanks for any insight you can provide,

Cody

Nov 17 '05 #1
6 1651
Cody,

The pattern for implementation indicates that the protected version is
used so that it can be overriden in derived classes (so that you can
properly dispose of the base).

However, the base class implementation of IDisposable is always going to
call the virtual/overriden method (the protected version takes a parameter,
and that doesn't satisfy the interface contract).

In short, yes, always use a using block. It allows for proper cleanup
of classes which implement IDisposable.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Cody Powell" <co**@codypowell.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
Greetings all,

I'm wondering if there's a rule of thumb related to objects that
implement IDisposable, but whose Dispose() methods are actually marked
as protected. If you dig around System.IO, you'll see a lot of these,
like StreamReader, StreamWriter, etc. Is it still a best practice to
wrap those objects in a using block?

All of the MSDN docs DO wrap such objects in a using block, but I'm
wondering if that actually accomplishes anything. Also, does anyone
know why the Dispose method is marked as protected on such objects?
Thanks for any insight you can provide,

Cody

Nov 17 '05 #2
Nicholas, thanks for the response.

I have one more question that's actually based on one of your comments.
If the protected version of Dispose takes a parameter and thus doesn't
satisfy the interface contract, how is something like StreamReader
actually implementing IDisposable?

In order to fulfill that contract, Dispose() has to be public and
accept zero parameters. I don't see anything that satisfies the
condition in the object or in the base class from which it's derived.
How is this working?

Thanks for clueing me in,

Cody

Nov 17 '05 #3
Cody Powell <co**@codypowell.com> wrote:
I'm wondering if there's a rule of thumb related to objects that
implement IDisposable, but whose Dispose() methods are actually marked
as protected. If you dig around System.IO, you'll see a lot of these,
like StreamReader, StreamWriter, etc. Is it still a best practice to
wrap those objects in a using block?

All of the MSDN docs DO wrap such objects in a using block, but I'm
wondering if that actually accomplishes anything. Also, does anyone
know why the Dispose method is marked as protected on such objects?
Thanks for any insight you can provide,


As Nick said, this is a general pattern which certainly *doesn't* mean
you shouldn't call the normal Dispose method.

See
http://tinyurl.com/2t03
http://tinyurl.com/bdw6g
for more details.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #4
StreamReader doesn't implement IDisposable. but if you take a look at the
base class TextReader which StreamReader derives from, you will see that it
has a explicit implementation of IDisposable.Dispose(). So StreamReader gets
the interface through inheritance.

and this is where the protected version of Dispose(bool) becomes important,
it allows StreamReader properly clean up after itself (by overriding),
without having to implement the interface seperately.

"Cody Powell" wrote:
Nicholas, thanks for the response.

I have one more question that's actually based on one of your comments.
If the protected version of Dispose takes a parameter and thus doesn't
satisfy the interface contract, how is something like StreamReader
actually implementing IDisposable?

In order to fulfill that contract, Dispose() has to be public and
accept zero parameters. I don't see anything that satisfies the
condition in the object or in the base class from which it's derived.
How is this working?

Thanks for clueing me in,

Cody

Nov 17 '05 #5
But TextReader <i>doesn't</i> actually have the proper Dispose()
method. Check it out in Intellisense and in the documentation:

http://msdn.microsoft.com/library/de...thodsTopic.asp

Daniel Jin wrote:
StreamReader doesn't implement IDisposable. but if you take a look at the
base class TextReader which StreamReader derives from, you will see that it
has a explicit implementation of IDisposable.Dispose(). So StreamReader gets
the interface through inheritance.

and this is where the protected version of Dispose(bool) becomes important,
it allows StreamReader properly clean up after itself (by overriding),
without having to implement the interface seperately.

"Cody Powell" wrote:
Nicholas, thanks for the response.

I have one more question that's actually based on one of your comments.
If the protected version of Dispose takes a parameter and thus doesn't
satisfy the interface contract, how is something like StreamReader
actually implementing IDisposable?

In order to fulfill that contract, Dispose() has to be public and
accept zero parameters. I don't see anything that satisfies the
condition in the object or in the base class from which it's derived.
How is this working?

Thanks for clueing me in,

Cody


Nov 17 '05 #6
I partly answered my own question, but it raised new questions.

http://msdn.microsoft.com/library/de...thodsTopic.asp.
The main frame of the page shows that the only Dispose method is the
protected Dispose(bool), which is not satisfying IDisposable. But look
in the small frame at the left. Only there, you see
"IDisposable.Dispose Method". Click on it, and you'll see that
this is the public no-parameter version that we were looking for. It
says "This member supports the .NET Framework infrastructure and is
not intended to be used directly from your code."

This method is declared inside the TextReader class like so: private
void IDisposable.Dispose( ) {...}

This is an "explicit interface implementation", meaning that you
can only see it when you've casted your object to IDisposable. But,
it's private!

MSDN doc on explicit interface implementation says "A class
implementing a file abstraction, for example, would likely implement a
Close member function that has the effect of releasing the file
resource, and implement the Dispose method of the IDisposable interface
using explicit interface member implementation".

Which raises new questions:

1) Why on earth would you want to hide this method? It breaks
Intellisense, so you can't tell that you should use a using
statement. If you want to hide it, then declaring it as IDisposable
doesn't *DO* anything.

2) How on earth can a private method satisfy an interface?

3) How on earth can the using statement call a private method?

4) What in the flying heck does TextReader.Close( ) do? Does it call
the private Dispose( )? Can we assume that it does, completely going
against every recommendation I've ever read about IDisposable,
Close(), and using?

Nov 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by RiteshDotNet | last post: by
1 post views Thread by John | last post: by
156 posts views Thread by Dennis | last post: by
9 posts views Thread by utab | last post: by
reply views Thread by Gonçalo Rodrigues | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.