Hi Adrian, > * IOException or other exception while reading from the stream. Our > input stream wrapper could catch this and release the connection then > rethrow the exception.
Aren't there fatal and non-fatal IOExceptions? If there is a read timeout, how are you going to decide whether the application is going to try again or not? > * Situations where the response from the server is discarded. This > is most common with error responses from servers like 404s etc but > can happen when the start of the response indicates in some software > specific manner that the rest of the content is irrelevant (eg: an > XML declaration that indicates that the file's version is 2.0 and not > supported by the parser). I'm not sure how to deal with this case > though requiring the user to close the input stream would match how > input streams are normally used, avoid having to read the entire > response and release the connection (the connection of course > couldn't be reused by that's probably a fair trade off given the > saving in not having to download the content). Sounds reasonable, though I would add a flag to switch between the abort() and releaseConnection() semantics when InputStream.close() is called. I suspect people tend to be sloppy when it comes to closing streams, especially when they are considered useless or faulty. But it wouldn't make that much difference if we told them to close the stream instead of telling them to release the connection. Especially if the stream is at hand, while the method is not. I'm not familiar with the new API yet, but if there still is a Method.releaseConnection() or HttpResponse.releaseConnection(), we could rename it to close() and then tell people: you have to close either the method/response or the stream you got from it. I'd like that better than explicitly calling a release method for something that was implicitly allocated. > Am I crazy? Thoughts? No, I don't think you're crazy :-) cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
