Late change to JEP 433

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "John Rose" <john.r.rose at oracle.com>
> Cc: "Alex Buckley" <alex.buckley at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Monday, November 14, 2022 11:40:27 PM
> Subject: Re: Late change to JEP 433

> 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)).
I still think we should throw a NPE when a destructuring something which is null. 

It will make the semantics of MatchException very similar to LambdaConversionException, i.e. a lot of users will never see it because it can be thrown only when there is a separate compilation issue or a bug in the deconstructor. 

If you take a look to the implementation, the NPEs can be thrown organically as the result of calling the deconstructor (or the accessor methods) on null, instead of adding a nullcheck that goto to the location where the MatchException is thrown. 

Rémi 

> 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" [ mailto:john.r.rose at oracle.com | <john.r.rose at oracle.com> ]
>>> To: "Alex Buckley" [ mailto:alex.buckley at oracle.com | <alex.buckley at oracle.com>
>>> ] Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <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/20221115/bc326e41/attachment-0001.htm>