<div dir="ltr"><div>Fair enough. I do see the grammatical appeal of "case throws" and agree that it reads better.<br></div><div><br></div><div>I might characterize your answer more as "yes, this syntax is not in line with the rest of the language, and that's how we want it". :-) In the rest of Java, "throw" and "throws" indicate where exceptions are emitted, and "catch" indicates where they are handled (as regrettable as the imperative nature of the word "catch" might be).
This would be the first time where "throws" introduces a syntax construct that does not throw the exception in question.<br></div><div><br>
</div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Patrick Doyle<br><a href="mailto:p.r.doyle@gmail.com" target="_blank">p.r.doyle@gmail.com</a></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 19, 2024 at 11:45 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<font size="4" face="monospace">No :)<br>
<br>
It was discussed why not to use bare "catch" on the EG list.
"Case catch" is slightly different, but I'd like to explain why
this is not in the spirit of the feature. <br>
<br>
To recap one of the reasons we rejected bare `catch`: because it
is asking a question _about the selector_ (did evaluating the
selector throw), not about the _block_ (did something in this
switch block throw.) If we called it catch, this would surely be
confusing. <br>
<br>
The essence of switch is "evaluate a thing, then do one of the
following things as a result." With an exhaustive switch with no
fall through, its "exactly one thing"; let's go with that as our
model: evaluate a thing, then do exactly one of the following
things. <br>
<br>
We pick which thing to do based on case selectors. Currently we
have case selectors for constants, patterns, and catch-all
(default). Each of these selectors should refer back _to the
computation_ that is the switch selector. A `case
<constant>` says "did it evaluate to this constant." A
`case <pattern>` says "did it evaluate to something that
matches this pattern." A `case throws <pattern>` says "did
it throw something that matches this pattern." But "case catch"
would be asking "did it evaluate to something that catches this
exception", which doesn't really even make sense. <br>
<br>
Further, I know we are all used to the word "catch" from
try-catch, but "catch" is a very imperative framing, which comes
from a day where language control constructs were all statements
(while, for, if, try, etc), not expressions. Over the last 30
years we've learned that statements suck. (Because, expressions
compose, and statements don't, and composition is the best tool we
have.) <br>
<br>
So I think the desire to hold onto "catch" here (in addition to
the problems discussed on the EG list) is mostly skating to where
the puck *was*, rather than where it is *going*. <br>
<br>
<br>
</font><br>
<div>On 2/19/2024 9:18 AM, Patrick Doyle
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>In Brian's "Uniform handling of failure in switch", he
proposes the syntax "case throws". I see the motivation (it
certainly reads nicely) but since such clauses are catching
exceptions, wouldn't it be more in line with the rest of the
language to use "case catch"?</div>
<div><br>
</div>
<div>This would also serve to preserve the word "throws" for its
usual purpose if ever "switch ... throws" becomes a thing.</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr" class="gmail_signature">--<br>
Patrick Doyle<br>
<a href="mailto:p.r.doyle@gmail.com" target="_blank">p.r.doyle@gmail.com</a></div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>