Late change to JEP 433

[Remi Forax]

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" <john.r.rose at oracle.com>
> To: "Alex Buckley" <alex.buckley at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> 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!”