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
