Rule of Thumb for a Protected Dispose() Method?

[Cody Powell]

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

[Nicholas Paldino [.NET/C# MVP]]

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.co m

"Cody Powell" <co**@codypowel l.com> wrote in message
news:11******** *************@g 47g2000cwa.goog legroups.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

[Cody Powell]

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

[Jon Skeet [C# MVP]]

Cody Powell <co**@codypowel l.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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Daniel Jin]

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.Dis pose(). 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

[patrick.lioi]

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.Dis pose(). 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

[patrick.lioi]

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.Di spose 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.Dis pose( ) {...}

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.Clos e( ) 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?