A brief reminder: this is getting out of the charter of amber-dev.
On 11/14/2022 5:58 PM, [email protected] wrote:
------------------------------------------------------------------------
*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
<[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
