Hi. Le dim. 27 juin 2021 à 17:37, Torsten Curdt <tcu...@vafer.org> a écrit : > > > Can you expand on that - I don't understand the horror or the futility. > > > > > The futility is because it is wrong for the caller to expect that no > > runtime exception can be thrown. > > > > Based on that premise we could also just forget about checked exceptions > altogether.
As Gary said (as Joshua Bloch said, as many people said), checked exceptions are for recoverable errors. > I think the distinction is that runtime exceptions are more for unexpected > errors. Agreed. > Parsing an archive I personally don't see in that realm. Even if the archive is just garbage (or any non-supported file format)? > > > It certainly is a bit of code smell - but only because there is no quick > > > way to harden the implementations. > > > > Maybe I do not follow what you mean, but there is no way to "harden": > > if the input is garbage, it cannot be processed and _some_ exception > > will result. > > > > If there are checks in place, the implementation could throw a checked > exception. > Harden as in adding those checks. The question is the rationale for choosing checked vs unchecked exceptions. > > But I rather have a clear and stable API and fix the the implementation > > > along the way than to leak the problems to the API consumer and just > > > document it. > > > > Signalling that a problem with the input was detected is not leaking > > since the problem was the API caller/consumer in the first place. > > [Fixing library bugs is not what is being discussed AFAICT.] > > > > I'd argue that signaling this problem should be a checked exception. > IMO this provides a clearer contract to the user. It doesn't. The user would have a false sense of security believing so. > I guess it's all about managing expectations. > If I throw garbage at a parser I'd not expect a runtime exception but a > ParseException. That's acceptable if the rationale is to behave like the JDK does in circumstances deemed similar. [But I still think that the one-rule of "recoverable or not" is easier to follow consistently.] > If it does throw a runtime exception instead it is leaking the problem as > invalid input is not something the caller can even check beforehand. In this particular case, it's true that we are on the fence for that very reason. It is however no less true that the error is not recoverable from the POV of the Commons library. For example, if it _could_ be checked beforehand that the input is wrong, we should (IMO) throw an IAE; hence it is indeed inconsistent that depending on how/when the error is discovered, the exception would be different. But as said previously, it could boil down to a choice of API. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
