> 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" [ mailto:[email protected] | >>> <[email protected]> ] >>> To: "Alex Buckley" [ mailto:[email protected] | >>> <[email protected]> >>> ] Cc: "amber-spec-experts" [ mailto:[email protected] | >>> <[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!”
