<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:327307323.80228032.1702420883408.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<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;">
<br>
Exception cases can be used in all forms of `switch`:
expression and statement<br>
switches, switches that use traditional (colon) or
single-consequence (arrow)<br>
case labels. Exception cases can have guards like any other
pattern case. </blockquote>
<div><br>
</div>
<div>I think I would prefer "case throws" to be spell "catch"
even if we have to have a discussion about catch(Throwable
t) vs catch Throwable t.<br data-mce-bogus="1">
</div>
</div>
</div>
</blockquote>
<br>
Ah, you've stepped in the trap. You know the rule: if you make a
syntax comment, you've implicitly signed up for all the semantics.
Glad to know you're on board :)<br>
<br>
We knew that someone (everyone?) would ask about this, because its
kind of the obvious choice. But having thought about it for quite a
while, I'm firmly convinced that this is in the "obvious but wrong"
department. PLEASE, let's not have a back-and-forth on this,
because I don't want a substantive discussion to be derailed by a
syntax triviality (we can return to this topic after the
substantitive discussions have played out), but I will summarize
some of the reasons why this is not what we want, because I think
they are relevant to the goals of the feature:<br>
<br>
- The semantics would be extremely confusing, because a `case
throws` matches only exceptions thrown _in evaluating the selector_,
just like other cases match the result of a successful evaluation of
the selector. But if we expressed this as `switch ... catch`, users
would forever be assuming, incorrectly, that they mean to be
catching all errors from the switch block, including both those from
the selector and those from the body. That is *not* what this
construct is about. <br>
<br>
- The *whole point* of this feature is allowing evaluation failures
to be handled consistently and uniformly with successful
evaluation. Having a different syntax for handling failures does
not help and does not highlight the uniformity. Again, that is not
what this constructs is about. <br>
<br>
The keyword `catch` is familiar but that is a very short-lived
benefit. The purpose of the feature is to allow uniform handling of
results and effects; the syntax should reflect that.<br>
<br>
<br>
<blockquote type="cite" cite="mid:327307323.80228032.1702420883408.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<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;"><br>
<br>
Exception cases have the obvious dominance order with other
exception cases (the<br>
same one used to validate order of `catch` clauses in
`try-catch`), and do not<br>
participate in dominance ordering with non-exceptional
cases. It is a<br>
compile-time error if an exception case specifies an
exception type that cannot<br>
be thrown by the selector expression, or a type that does
not extend<br>
`Throwable`. For clarity, exception cases should probably
come after all other<br>
non-exceptional cases. <br>
<br>
When evaluating a `switch` statement or expression, the
selector expression is<br>
evaluated. If evaluation of the selector expression throws
an exception, and<br>
one of the exception cases in the `switch` matches the
exception, then control<br>
is transferred to the first exception case matching the
exception. If no<br>
exception case matches the exception, then the switch
completes abruptly with<br>
that same exception. </blockquote>
<div><br data-mce-bogus="1">
</div>
<div>I don't want to be the guy implementing this :)</div>
</div>
</div>
</blockquote>
<br>
Good news, Jan has volunteered to be that guy :)<br>
<br>
<blockquote type="cite" cite="mid:327307323.80228032.1702420883408.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<div>I understand the appeal of such construct, it's a way to
switch (eheh) from a world with exceptions to a more
functional world where errors are values.<br data-mce-bogus="1">
</div>
<br>
</div>
</div>
</blockquote>
<br>
And even more so, to allow existing effectful APIs (like
Future::get) to be consumed as uniformly as they are implemented. <br>
<br>
<br>
</body>
</html>