<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">A brief reminder: this is
getting out of the charter of amber-dev. <br>
<br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 11/14/2022 5:58 PM,
<a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a> wrote:<br>
</div>
<blockquote type="cite" cite="mid:107377019.45464042.1668466709989.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div><br>
</div>
<div><br>
</div>
<hr id="zwchr" data-marker="__DIVIDER__">
<div data-marker="__HEADERS__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Archie Cobbs" <a class="moz-txt-link-rfc2396E" href="mailto:archie.cobbs@gmail.com"><archie.cobbs@gmail.com></a><br>
<b>To: </b>"Nathan Reynolds"
<a class="moz-txt-link-rfc2396E" href="mailto:numeralnathan@gmail.com"><numeralnathan@gmail.com></a><br>
<b>Cc: </b>"Brian Goetz" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a>,
"John Hendrikx" <a class="moz-txt-link-rfc2396E" href="mailto:hjohn@xs4all.nl"><hjohn@xs4all.nl></a>, "Remi Forax"
<a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a>, "amber-dev"
<a class="moz-txt-link-rfc2396E" href="mailto:amber-dev@openjdk.org"><amber-dev@openjdk.org></a>, "amber-spec-experts"
<a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.java.net"><amber-spec-experts@openjdk.java.net></a>, "Ron Pressler"
<a class="moz-txt-link-rfc2396E" href="mailto:ron.pressler@oracle.com"><ron.pressler@oracle.com></a><br>
<b>Sent: </b>Monday, November 14, 2022 5:33:35 PM<br>
<b>Subject: </b>Re: Retiring Checked Exceptions Was:
Throwing Functions<br>
</blockquote>
</div>
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div dir="ltr">
<div dir="ltr">On Sat, Nov 12, 2022 at 5:26 PM Nathan
Reynolds <<a href="mailto:numeralnathan@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">numeralnathan@gmail.com</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>> I've found that there are a lot of people
out there who quietly think checked exceptions are
... pretty OK.</div>
<br>
<div>Count me in this camp. Checked exceptions are
so much better than error return codes.</div>
</div>
</blockquote>
<br>
<div>I like checked exceptions also.</div>
<br>
<div>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?</div>
<br>
<div>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.</div>
<br>
<div>
<div class="gmail_quote">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).</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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)</div>
<div class="gmail_quote"><br>
</div>
</div>
</div>
<div class="gmail_quote">So here's my opinion on what we
should be optimizing for, from my own little
perspective.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.).<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">But the windows on my screen are
only ~54 lines tall.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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?</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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?</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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?<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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?</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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??<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Features that help my cause:</div>
- Compile time explicit strong typing
<div class="gmail_quote"> - Precisely defined semantics
(compare to C: order of execution, memory model, etc.)<br>
</div>
<div class="gmail_quote"> - Easily accessible Javadocs
that specify behavior precisely</div>
<div class="gmail_quote"> - Compiler warnings</div>
<div class="gmail_quote"> - <a class="gmail_plusreply" id="plusReplyChip-0" moz-do-not-send="true">@Overrides</a><br>
</div>
<div class="gmail_quote">
<div class="gmail_quote"> - Checked exceptions</div>
<div class="gmail_quote"><br>
</div>
</div>
<div class="gmail_quote">Features that don't help my cause
(they're not bad, they're just less important):</div>
- Anything that optimizes for the speed of writing code
rather than the speed of reading it
<div class="gmail_quote">
<div class="gmail_quote"> - Anything that optimizes for
code brevity (if that were the goal, we'd all be using
perl!)<br>
</div>
<div class="gmail_quote">
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">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.<br>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Java's "target market" as it
were is large enterprise projects. Regarding such
projects, a wise person once said: <i>You write
code once, but you maintain it forever.</i></div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>What if checked exceptions work like unchecked casts ?<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>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<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div> public void m() throws IOException {<br data-mce-bogus="1">
</div>
<div> var input = ...<br data-mce-bogus="1">
</div>
<div> Runnable runnable = () -> {<br data-mce-bogus="1">
</div>
<div> input.read();<br data-mce-bogus="1">
</div>
<div> };<br data-mce-bogus="1">
</div>
<div> runnable.run()<br data-mce-bogus="1">
</div>
<div>; }<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>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() ? <br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>So IOException will work seamlessly with streams, methods
that takes lambdas, etc.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div class="gmail_quote"><br>
</div>
</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">-Archie<br>
</div>
<div class="gmail_quote"><br>
</div>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">Archie L. Cobbs</div>
</div>
</blockquote>
<div><br>
</div>
<div>Rémi<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>