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