Le jeu. 29 juin 2023 à 16:33, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > > 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
At that point, and more than 10 minutes on, you explain the advantages of exception vs no exception. There is no debate: "exception" is much better than error-code checking. It was already in C++. > > > > > > 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. I think I can understand your rationale: Something that can be corrected at runtime should be signalled by a checked exception. Right? However I don't understand why you now add "Error" to the mix... And that's possibly the main issue: There is no convincing use-case for so many "Throwable" categories at the JDK level: What is recoverable, or not, is ultimately a domain-related convention, and also perhaps a matter of definition in the context of a particular design. And the unchecked exception is simply the most convenient because it provides the significant advantage (over error code checking) while not forcing anyone to litter the code with mandatory "throws" clause, even if the code does not intend to handle any of the advertised exceptions. > > > 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. It's not necessarily a "bug" in the sense of "programming error". For example, a program reads user input with some rule on whether to accept it. If not accepted it throws. Whether it's recoverable depends on the wanted functionality (e.g. allow multiple attempts or not). > > > 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. Sure but, as said, this trivial help from the compiler is by far not worth the trouble that comes with the usage of even a single checked exception. Best regards, Gilles > > > > 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
