My bad; I thought <:RuntimeException and wrote <:Error.
On 14 Nov 2022, at 14:40, Brian Goetz wrote:
Its MatchException. Error would not be appropriate, since this is
the same exception that gets used for remainder (e.g., Box(Box(var x))
against a target of Box(null)).
On 11/14/2022 5:31 PM, Remi Forax wrote:
I'm confused, is it MatchError or MatchException ?
Because if it's an error instead of an exception, it may be less an
issue in term of backward compatibility but it is not what is
proposed, right ?
Rémi
----- Original Message -----
From: "John Rose"<[email protected]>
To: "Alex Buckley"<[email protected]>
Cc: "amber-spec-experts"<[email protected]>
Sent: Monday, November 14, 2022 8:24:04 PM
Subject: Re: Late change to JEP 433
On 14 Nov 2022, at 10:56, Alex Buckley wrote:
… ICCE can hand over to MatchException …
Precisely; I agree that it is time for this to happen. Thanks, Alex
for
reminding us of the history and lineage of ICCE, and why it
doesn’t make sense
for switch statements (not even classic switch-over-enum).
As a program linkage error, ICCE is necessarily uncommunicative when
applied to
a misconfigured switch statement. Using a MatchError is on the
other hand
highly informative: The user (and possibly try/catch logic
surrounding the
failure) knows exactly what happened, that a set of matches expected
to succeed
has failed.
So, here’s a possible knock-on advantage if we hand off from ICCE
to ME: If
there is further development of the concept of “a set of matches
which is
required to succeed”, the error processing can continue to be
unified under the
ME. Brian’s ideas about “let-statements” entail a single
pattern which is
required to match; ME is surely the right way to signal failure (if
not
something more specific like CCE or NPE, which is an interesting
side-conversation). Or, if we ever did Haskell-style method
overloads that
discriminate arguments by means of patterns, surely they would
desugar to
omnibus methods that start with switches; once again ME surely makes
sense as a
way to signal inapplicability of such match-based methods.
— John
P.S. More speculatively, and probably a bridge too far, would be to
employ
MatchException as a part of a meta-language protocol that defines
how sets of
patterns compose, and in particular how one part of a composite
signals failure
to the whole composite. (Surely there is some future use for X in
methods :
method handles :: patterns : X; that’s what I mean by a
meta-language
protocol.) I say this is a bridge too far because Java exceptions
are not a
very good tool for normally-frequent control flow, and also because
ME, like
NPE or CCE, probably best signals a failure of the programmer’s
settled
intentions about some code, rather than signaling an alternative
control path
(like if/else). Still, I wanted to point this out because in other
languages
exception-like concepts are used to convey backtracking out of
composite
control flow patterns, and if we decided to try this out for Java,
MatchExpression would raise its hand and say “pick me!”
