<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>