<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Counter-proposal: let's just
        retire the endless stream of "let's just get rid of checked
        exceptions" proposals instead.  <br>
        <br>
        This is all well-traveled ground, and has all been brought up
        before (including by you several times.)  I get how attractive
        it is to "just" declare checked exceptions a mistake.  But even
        if it was, we know that trying to "fix" the "mistakes" of the
        past often only makes things worse.  <br>
        <br>
        There is interesting research going on in the Scala community
        and elsewhere about better treatment of effects; some of this
        may bear fruit that might be a better approach than the "just
        uncheck them all."  In any case, I'm not interested in reopening
        this discussion at this time; we have plenty else on the
        priority list.  <br>
        <br>
        Verdict: Motion Denied.  Leave is granted to refile your motion
        in 2025.  <br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 11/12/2022 2:58 AM, Remi Forax
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:839324466.44117145.1668239937777.JavaMail.zimbra@u-pem.fr">
      
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div>[promoted to amber-spec-experts]<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>I think we should tackle this problem at its core and
          retire the notion of checked exceptions</div>
        <div><br data-mce-bogus="1">
        </div>
        <div>The written are on the wall since quite some time, but we
          have not yet acknowledge it.</div>
        <div><br data-mce-bogus="1">
        </div>
        <div>Let's recap the issue and the clues pointing in that
          direction.<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>I believe the first straw can be tracked back to the
          inability of the type system to create a type variable
          containing the union of exceptions when generics where
          introduced in Java 5.<br>
        </div>
        <div>It's the reason why there is no ThrowableConsumer, as an
          example, imagine that a stream can declare a checked exception
          Stream<T, E> and a user call map() that takes a
          ThrowableFunction,<br data-mce-bogus="1">
        </div>
        <div>we need a way to express that the resulting stream is that
          combine the exceptions of the original stream and the
          exceptions that may be raised by calling the function of map.<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>  Stream<T, E extends Exception>  --> 
          map(ThrowableFunction<T, R, F extends Exception>) 
          -->  Stream<R, E | F><br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>Or perhaps from the beginning of Java, adding a checked
          exception to a "throws" colors the function the same way the
          keyword async or Rust lifetime type information color a
          function [1]. Adding a checked exception to a function is not
          a backward compatible change.<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>So we have some of idioms that beginners need to
          internalize to try workaround checked exceptions,<br data-mce-bogus="1">
        </div>
        <div>- The oldest is i think, Thread.currentThread().interrupt()
          which allows to silence an InterruptedException at the price
          of continuing to execute the code until the next blocking call</div>
        <div>- UncheckedIOException and IOError that both wrap an
          IOException into an unchecked exception allowing tunneling of
          checked exceptions ; wrapping an IOException and unbundle it
          later.<br data-mce-bogus="1">
        </div>
        <div>- Unsafe.rethrow (this one was retired)<br data-mce-bogus="1">
        </div>
        <div>- the unfamous rethrow using erasure to see a checked
          exception as an unchecked exception<br data-mce-bogus="1">
        </div>
        <div>   static <T extends Throwable> AssertionError
          rethrow(Throwable cause) throws T {<br>
                throw (T) cause;<br>
             }<br>
          - IntelliJ has changed the default try/catch snippet to
          instead of calling printStackTrace() to throw a
          RuntimeException wrapping the exception.<br data-mce-bogus="1">
        </div>
        <div>  This simple change is i believe the best change to Java
          in the recent years (perhaps toes to toes with records), at
          least now the code of my students does not print the stack
          trace and resume its course when an exception occurs.<br>
        </div>
        <div>    try {<br data-mce-bogus="1">
        </div>
        <div>     ...<br data-mce-bogus="1">
        </div>
        <div>    } catch(FooException e) {<br data-mce-bogus="1">
        </div>
        <div>      throw new RuntimeException(e);<br data-mce-bogus="1">
        </div>
        <div>    }</div>
        <div><br data-mce-bogus="1">
        </div>
        <div>Also no language presented as potential successor of Java,
          neither Scala nor Kotlin have checked exceptions, because
          functions with checked exceptions do not compose.<br data-mce-bogus="1">
        </div>
        <div>If Java wants to be the next Java, we will have to drop
          checked exceptions at some point.<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>The good news is that seeing all exceptions as unchecked
          exceptions is a backward compatible change, "throws" can still
          be supported for documentation purpose, the compiler can emit
          a warning instead of an error if there is no catch
          corresponding to a checked exception and allow everyone to
          catch any exceptions in the code.<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>I think we should recognize that the idea of checked
          exceptions was a good idea on paper but not a good one in
          practice and work to retire the concept of checked exceptions
          from Java.</div>
        <div><br data-mce-bogus="1">
        </div>
        <div>RĂ©mi<br data-mce-bogus="1">
        </div>
        <div><br data-mce-bogus="1">
        </div>
        <div>[1]
<a class="moz-txt-link-freetext" href="https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/">https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/</a><br data-mce-bogus="1">
        </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>"Nathan Reynolds" <a class="moz-txt-link-rfc2396E" href="mailto:numeralnathan@gmail.com"><numeralnathan@gmail.com></a><br>
            <b>To: </b>"amber-dev" <a class="moz-txt-link-rfc2396E" href="mailto:amber-dev@openjdk.org"><amber-dev@openjdk.org></a><br>
            <b>Sent: </b>Saturday, November 12, 2022 5:47:10 AM<br>
            <b>Subject: </b>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>I am sorry if I am very late to the discussion. 
                Consumer, Function, Predicate, and Supplier don't allow
                for throwing checked exceptions.  This feature is needed
                in many cases.  What about adding a variant that allows
                for throwing checked exceptions?  For example, a
                ThrowableConsumer could be defined as such...</div>
              <br>
              <div>public interface ThrowableConsumer<T, E extends
                Throwable></div>
              <div>{</div>
              <div>   void accept(T t) throws E;</div>
              <div>}</div>
              <br>
              <div>A method that receives this as a parameter could be
                defined as such...</div>
              <br>
              <div>public <E extends Throwable> void
                process(ThrowableConsumer<T, E> consume) throws E</div>
              <div>{</div>
              <div>   ...<br>
              </div>
              <div>}</div>
              <br>
              <div>The compiler takes care of ensuring the checked
                exception is dealt with in the caller to process().</div>
            </div>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>