Late change to JEP 433

[Brian Goetz]

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"<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!”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20221114/38558608/attachment.htm>