Checked exceptions are also used when the error isn’t a programmer error. >From an aesthetic perspective, I prefer the unchecked exceptions unless an API already established them. Subclassing IOException is fairly common for example.
On Sun, Jun 27, 2021 at 10:37 Torsten Curdt <tcu...@vafer.org> wrote: > > 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. > > I think the distinction is that runtime exceptions are more for unexpected > errors. > Parsing an archive I personally don't see in that realm. > > > > > 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. > > > 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. > > 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. > 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. >
