On Thu, Jun 29, 2023 at 10:10 AM 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
tldr; he's wrong. More details: https://www.youtube.com/watch?v=rJ-Ihh7RNao&t=419s > > > > 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. Libraries you link to are not external to the program. Runtime exceptions might be appropriate here. > 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--- This is about the only thing in that book where I disagree with Bloch. At the very least this is not said as well as it needs to be. Recoverable vs unrecoverable distinguishes Errors from Exceptions, not runtime exceptions from checked exceptions. You can interpret that sentence to mean "bugs are not recoverable short of fixing the code" in which case sure, runtime exceptions are not recoverable. > For example, *all* precondition failures are, from the POV of the > called function, a programming error (akin to NPE or IAE). This is correct. NPEs and IAEs are programming errors. > 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"). It's not about the root cause. It's about the immediate cause. Passing null or another illegal argument to a method that isn't ready to receive it is a programming error, i.e. a bug, and therefore these are properly runtime exceptions. > > 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. Had the JSON library properly used checked exceptions, the programmer would not have been able to compile code that contained this mistake. The reason we have strong static typing, unit tests, and checked exceptions is that programmers are imperfect humans. Let the machines do the work that machines are good at, including checking whether errors are properly handled. > > 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... :-) There's more than one reason. :-) -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
