Great presentation in the video Elliotte. Thanks for sharing the link. Gary
On Thu, Jun 29, 2023, 10:33 Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > 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 > >
