Hi. > [...]
> it seemed Gilles was opposed to this idea Rather (IIRC) my last comment was that it was your choice as to what the API should look like. My opinion on the matter was along Gary's lines (which is J. Bloch's rationale provided in "Effective Java"). Indeed I personally would indeed *not* pick option 1 because it puts the onus on the Commons library whereas input that does not comply with preconditions (i.e. a supported format) should unsurprisingly throw an IAE. Of course, this is also a matter of taste e.g. if one wishes to behave similarly to the JDK for things like "FileNotFoundException"... > [...] Le dim. 27 juin 2021 à 15:06, Torsten Curdt <tcu...@vafer.org> a écrit : > > > feels like both a horror show and an exercise in futility > > > 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. > 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. > 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.] Regards, Gilles > > For me it's not about "appease some tool" it's just that the tool has > revealed a problem and we have to decide how to deal with this in the > future. > > cheers, > Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
