Re: Why should close() close the underlying stream?
Silvio Bierman wrote:
Lew wrote:
Daniel Pitts wrote:
Although, as has been mentioned, usually if you close a stream, you
really DO want to close the underlying streams too.
I can't seem to think of a use case for not closing the underlying
stream. Every time I think I have one, it's simpler not to close the
stream at all.
Hello Lew,
I had some use cases for this in the past. I was writing a compound XML
doc to an OutputStream (HTTP response) and needed a library to write an
XML representation of one of it's object instances somewhere in to an
element in the total XML doc.
Unfortunately the library insisted on closing the stream that I passed
it. Off course that would prevent me to complete the surrounding XML
document.
I needed to be able to pass it an OutputStream that would just extend my
current OutputStream and then just flush it when it was done. Simple
enough, off course.
Just create a wrapping OutputStream that only calls wrapped.flush() in
its close method.
Another approach might be to use a SequenceInputStream.
You would pass individual PipedOutputStream objects to the
libraries that write and close, connecting their other ends
to PipedInputStreams that feed the SIS, which you'd then
just read and copy to the final output.
Or if the library doesn't generate "too much" data you
could hand it a ByteArrayOutputStream, let it be written and
closed, and then dump its data to your actual output.
There may be a couple dozen ways to skin this cat ...
--
Eric Sosman
esosman@ieee-dot-org.invalid