> From: "Archie Cobbs" <[email protected]> > To: "Nathan Reynolds" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "John Hendrikx" <[email protected]>, > "Remi Forax" <[email protected]>, "amber-dev" <[email protected]>, > "amber-spec-experts" <[email protected]>, "Ron Pressler" > <[email protected]> > Sent: Monday, November 14, 2022 5:33:35 PM > Subject: Re: Retiring Checked Exceptions Was: Throwing Functions
> On Sat, Nov 12, 2022 at 5:26 PM Nathan Reynolds < [ > mailto:[email protected] | [email protected] ] > wrote: >>> I've found that there are a lot of people out there who quietly think >>> checked >> > exceptions are ... pretty OK. >> Count me in this camp. Checked exceptions are so much better than error >> return >> codes. > I like checked exceptions also. > But so what? Of course everyone including me is going to have some opinion... > the deeper question is, what are we trying to optimize for in a programming > language? > Well I'm sure everyone has an opinion on that question as well.. but at least > that question is a little closer to the heart of the matter. > A problem I've seen with programming language design happens in other fields > as > well. Consider building architecture for example. Architects can sometimes > drift from optimizing for the humans that will occupy the space (what should > be > their goal) to optimizing for simplicity, beauty, and elegance (what they > really want to be their goal). > Simplicity, beauty, and elegance are all well and good until they start > detracting from the more important goal of serving the humans. Have you ever > had dinner in a nice restaurant that has sleek & beautiful architecture, but > because of all the open space it's really drafty and because of the hard > concrete ceilings and resulting terrible acoustics you can barely understand > what anyone across the table is saying? (yes, that just happened a few weeks > ago) > So here's my opinion on what we should be optimizing for, from my own little > perspective. > I'm not a language designer (those folks are a lot smarter than me :) I'm > just a > regular Java user for 20+ years. My main development responsibility right now > is an enterprise web application with ~150,000 lines of code, plus millions of > LOC incorporated by reference (Spring, Hibernate, Tomcat, Linux, etc.). > But the windows on my screen are only ~54 lines tall. > That means I can inspect at most 0.03% of the code at any one time, and yet > I'm > supposed to somehow ensure this whole thing works properly without any bugs. > Therefore, to me the most important property of a programming language is > this: > how hard is it to look at a chunk of code on the screen and be able to > convince > myself that it will do what it's supposed to and not contribute any bugs? > Is most of the critical information there in front of me? Can I convince > myself > I'm looking at a seaworthy vessel of logical correctness? > Or are there a bunch of "leaks" that I either have to patch, or (almost worse) > do a bunch of research to finally realize that in fact they really aren't > leaks > after all? > How hard is it to hunt down the information that's not explicitly on the > screen > that I need to feel confident in what I'm looking at? > No doubt Java would be more simple, beautiful, and elegant without checked > exceptions. But checked exceptions are explicit information on the screen > relating to what error cases can possibly occur. They appear pretty much when > and where you need to see them. And the compiler guarantees that you won't > accidentally miss one. > From the perspective of "Help me prove this code is correct and handles all > the > possible error cases" what's not to love about that?? > Features that help my cause: > - Compile time explicit strong typing > - Precisely defined semantics (compare to C: order of execution, memory model, > etc.) > - Easily accessible Javadocs that specify behavior precisely > - Compiler warnings > - @Overrides > - Checked exceptions > Features that don't help my cause (they're not bad, they're just less > important): > - Anything that optimizes for the speed of writing code rather than the speed > of > reading it > - Anything that optimizes for code brevity (if that were the goal, we'd all be > using perl!) > An example of the latter is the new "var" keyword. Yes it makes it faster to > WRITE code, but it makes it a tiny bit slower to READ code. It means to > understand what "foo" is, I have to do one little tiny extra step of type > inference in my head. Not a big deal, and I'm certainly not opposed to the > feature, but I probably won't use it much. > Java's "target market" as it were is large enterprise projects. Regarding such > projects, a wise person once said: You write code once, but you maintain it > forever. What if checked exceptions work like unchecked casts ? What if instead of a compiler error you still have a warning when you suppress a checked exception, so you can write code like this public void m() throws IOException { var input = ... Runnable runnable = () -> { input.read(); }; runnable.run() ; } and you get two warnings, one because you have suppressed the IOException inside the Runnable and one because you have a throws IOException with no IOException thrown inside the body of m() ? So IOException will work seamlessly with streams, methods that takes lambdas, etc. > -Archie > -- > Archie L. Cobbs Rémi
