Late change to JEP 433

[John Rose]

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"<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/b10ad6f3/attachment-0001.htm>