Adding my two cents here... It's very important to me as a user and developer to have informative errors. If I use compress in my application and a raw NPE or out of bounds exception flies out of the code with little to no context and makes it out to the end user, then I am going to be getting a call as to why my code is broken. It is also going to take me quite a while to track down the source of the error and will most likely involve me digging into the compress source code at some point. On the other hand, if the user receives an exception like Stefan's UnhandledInputException [1] or a CorruptedArchiveException, then they may try to check the archive itself first and not even call me, and even if they do call, I'll be able to troubleshoot much more quickly. That is why I think Stefan's PR (or something similar) is the best way to go: it adds useful information to the error that would be very difficult to obtain otherwise.
Regards, Matt J [1] https://github.com/apache/commons-compress/compare/catch-RuntimeExceptions On Thu, Jul 1, 2021 at 6:04 PM Gilles Sadowski <gillese...@gmail.com> wrote: > > [...] > > > One is "sorry, this is an invalid archive" while the other is > "something > > > > went wrong reading the archive - printStackTrace". If that > distinction is > > > > not important to you - so be it. To me that's a big difference. > > > > > > Never said such a thing. > > > > > > > Not sure what "thing" you mean exactly but In the very same email you > wrote: > > > > "I don't see why the library should be expected to explain in details > > why an archive is corrupt; it is good enough that it can detect it..." > > Cases in point (example provided by Stefan) is that exceptions are > raised by bad input, but the exact reason is not always known because > the processing could continue for some time before the optimistic > assumption turned out to be wrong. > For sure, it is better to provide the actual root cause of the failure but > Stefan indicated that reviewing all the codes would be a lot of work. > And IIUC, we are talking about the current situation, not the ideal one > (where the caller could act based on accurate information). > > IOW still, what I meant by the above is that this pseudo-code (I have > no idea how the [Compress] API looks like): > ---CUT--- > String foo = "This is probably invalid ZIP data"; > String bar = compress.unzip(foo); > ---CUT--- > could throw a plain IAE, without being required to give an explanation > of why/how/where the library figured out that something was wrong > with the input. Providing wrong input is a programming error on the > caller's part. It's his responsibility to protect against his mistakes. > > > > The "sorry, this is an invalid archive" is what makes the situation > > > > for me "recoverable". > > > > > > This is plain wrong: > > > > > > I am not drawing that straight line to preconditions. > > Flows or processes can also have the attribute of "recoverable". > > Not [Compress] responsibility. > > > [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
