Retiring Checked Exceptions Was: Throwing Functions

[forax at univ-mlv.fr]

> From: "Archie Cobbs" <archie.cobbs at gmail.com>
> To: "Nathan Reynolds" <numeralnathan at gmail.com>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "John Hendrikx" <hjohn at xs4all.nl>,
> "Remi Forax" <forax at univ-mlv.fr>, "amber-dev" <amber-dev at openjdk.org>,
> "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "Ron Pressler"
> <ron.pressler at oracle.com>
> 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:numeralnathan at gmail.com | numeralnathan at gmail.com ] > 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221114/cae0523c/attachment-0001.htm>