> I never could find a convincing example of "recoverable conditions".
Really? How about typing in a bad server name, user name, or password? That's a classic recoverable exception (in JDBC land for example). Gary On Thu, Jun 29, 2023, 10:11 Gilles Sadowski <gillese...@gmail.com> wrote: > Le jeu. 29 juin 2023 à 15:22, Elliotte Rusty Harold > <elh...@ibiblio.org> a écrit : > > > > On Thu, Jun 29, 2023 at 9:07 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > > Hello. > > > > > > Le jeu. 29 juin 2023 à 14:44, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > > > I agree with the second part assuming the *current* Java > > > best practices, not because of old APIs that are here to stay > > > only because of infinite backwards compatibility, and not > > > because they are deemed perfect. > > > > > > Best practices on this haven't changed since Java 1.0 (Possibly Java > > 1.0 alpha 3 if I recall versions correctly). > > > > Checked exceptions: all errors arising from external input to the > program. > > Runtime exceptions: program bugs > > A pile of arguments (tally is largely against *any* use of checked > exceptions): > > https://ohadshai.medium.com/its-almost-2020-and-yet-checked-exceptions-are-still-a-thing-bfaa24c8997e > > > > > I don't know which applies here, but 99% of the time this is all you > > need to consider to figure out whether a checked or runtime exception > > is called for. There are indeed a lot of old broken APIs that don't > > follow these simple rules, > > The rules which you stated are far from simple because "external" > depends on the POV (more below). > > Commons components like [RNG], [Geometry], [Numbers], [Math] > only throw unchecked exceptions. > > The only rule that ever made sense to me is from J. Bloch's "Effective > Java": > ---CUT--- > Use checked exceptions for recoverable conditions and runtime > exceptions for programming errors > ---CUT--- > > I never could find a convincing example of "recoverable conditions". > > In any case, Bloch's rule implies that there are several orders of > magnitude more conditions that should raise an unchecked exception > that there are for checked ones. > For example, *all* precondition failures are, from the POV of the > called function, a programming error (akin to NPE or IAE). > Whether the root cause is an "internal" or "external" error is irrelevant > at the point where the issue is detected (where the runtime exception > just conveys that "the call was inappropriate"). > > > and it's never fun when a system goes down > > in production because some random JSON yahoo thought checked > > exceptions were "icky". > > A bug of the application, by the "absent-minded" developer mentioned > in the previous mail. In Java, nothing prevents the throwing of a runtime > exception; the developer *always* must enclose "foreign" code in a > "try/catch" block, to protect the system. There is no need for checked > exceptions just to remember this (really) simple rule. > > > > > Lately I've been working in Python, and error handling practice in > > this community is abominable. The lack of checked exceptions is a > > large reason why Python code is expected to be unreliable and Python > > programs routinely dump stack. > > I've heard that it's rather the result of "script"-oriented design, or lack > thereof... :-) > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
