Retiring Checked Exceptions Was: Throwing Functions

[Archie Cobbs]

On Sat, Nov 12, 2022 at 5:26 PM Nathan Reynolds <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.*

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221114/a9b5fc20/attachment.htm>