> > By "AutoClose", I guess you mean that it will close itself if the EOF
> > is read?  That makes sense.
> 
> Yes. AFAIK that already happens in HttpClient 3.x. We just don't
> tell anybody, so keep it to yourself... ;-)

I believe auto-close is a mistake (as is keeping it a secret :-).  The
code using the stream isn't notified when it's closed, which leads to
unexpected IOExecptions.

E.g., I wrap the result of getResponseBodyAsStream() in a
BufferedInputStream because I sometimes need to reset() and reread
some of the data.  I read from the BufferedInputStream, which fills a
buffer from the underlying stream, which hits EOF and closes itself.
I get all the data I asked for from the BufferedInputStream, then
innocently call available(), which calls available() on the underlying
stream, which throws IOExecption.  The workaround I use is to first
wrap the AutoCloseInputStream in an EofMonitoringInputStream, which
watches for -1 returns from read(), skip(), etc., and sets an internal
EOF flag that it uses to avoid calling methods on the closed stream.
This works ok, but is hardly elegant.  I think this example
demonstrates that Java's stream architecture doesn't anticipate that
streams will close themselves in non-error situations.

I appreciate that some find the auto-close behavior useful, but I think
it should be optional (and documented).

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to