> [...] > > 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
