Late change to JEP 433
John Rose
john.r.rose at oracle.com
Mon Nov 14 22:51:19 UTC 2022
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>
More information about the amber-spec-experts
mailing list