I win my bet! I had my money on "If you send this, Remi will surely
attempt to reopen his pet NPE issue." We have been through this all
before, so unless you have something dramatically new and compelling,
we're not reopening this issue now.
As a reminder, not all causes of MatchException come from separate
compilation anomalies. Some come from match remainder, which is just an
ordinary domain error, and separating the two is only possible in the
easy cases.
I am not sure you fully understand how this works, otherwise you
wouldn't keep raising the same issue after getting the same
explanation. (For example, the "NPE can be thrown organically" claim
you make here, which you've made before, is wrong; it is possible a
later pattern can match Box(null), and we do not throw ME until all
choices are exhausted.)
On 11/14/2022 6:23 PM, [email protected] wrote:
------------------------------------------------------------------------
*From: *"Brian Goetz" <[email protected]>
*To: *"Remi Forax" <[email protected]>, "John Rose"
<[email protected]>
*Cc: *"Alex Buckley" <[email protected]>,
"amber-spec-experts" <[email protected]>
*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"<[email protected]>
To: "Alex Buckley"<[email protected]>
Cc: "amber-spec-experts"<[email protected]>
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!”
