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