https://issues.apache.org/bugzilla/show_bug.cgi?id=57296
Torsten Krah <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #7 from Torsten Krah <[email protected]> --- The ticket is about a more robust usage of the close method and the exception handling of the provided InputStream - it has nothing to do in the first place about some password protected files or such stuff (didn't write anything about that). Its afaik good practice that libraries, such as poi, should not close InputStreams they did not create but are provided with. Its the responsibility of the creator to close it. In this case if poi would not close those stream i could work with the Extractor: ################ InputStream in = ... Use poi stuff close the stream and handle exception if needed ################ I would know exception would be at "close" time and not at reading the stream. Currently POI closes the stram and i don't know that it was only at close time at runtime - i am only getting an IOException from POI - i don't know why without doing stack rewinding to look if it was from a read or close call. The close call could be ignored in my case - the read of cause can't be ignore because it would be an invalid TextExtractor instance. But POI does close the stream after it does successfully read all data from the stream. The Interface from close from the InputStream does specify an IOException may be thrown - so any Stream provided may throw such an exception (the BadBadding one was only an example where this does happen now with the JDK upstream change) - that's why the subject of the ticket is called: "should catch IOExceptions on "close" after successfully reading" So the question in this ticket is, why POI is not more robust here and handle those exception on close - because what was needed was read as far as i understand the Code i've looked at. It doesn't make sense to wrap the close in another stream (which i am currently doing as a workaround until this is hopefully addressed) and ignore it there because in this case you would need to tell all users if they ever use this method from the Extractor with an InputStream, that they must provide an InputStream which must not throw an exception when closed, because they won't be able to use POI at all if they can't assure that - which not all users can make sure without wrapping it, because they may be also provided with an InputStream from which they don't know if it may throw an Exception on close - in doubt it may do so, because the Interface does allow it. So my proposal is: 1. Don't close the stream you did not create, just read from it until you are finished and let the creator of the stream handle the close. 2. If you really want to close it be more robust and handle the exception - it can be ignored imho so you can at least catch and ignore or log it at this place. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
