Fwd: Pattern matching remainders
Brian Goetz
brian.goetz at oracle.com
Wed Mar 30 17:49:02 UTC 2022
The following was received on amber-spec-comments.
It's a cute idea, but it's not a precedent I want to set:
- Catch clauses cannot specify interfaces, and this is a nontrivial
change;
- Going down this road for pattern matching would likely generate a
significant stream of RFEs for new interfaces to be retrofitted to
existing exceptions;
- Having NPE acquire a pile of new supertypes is likely to be
confusing to users who arrive at the Javadoc page;
- The payoff is just not that big;
- There are already well-established techniques for providing
additional cause information for debugging -- exception text and wrapping.
So overall, I don't see the benefits justifying the costs.
-------- Forwarded Message --------
Subject: Pattern matching remainders
Date: Wed, 30 Mar 2022 18:38:11 +0100
From: Izz Rainy <izzeldeen03 at gmail.com>
To: amber-spec-comments at openjdk.java.net
Instead of having compilers potentially wrap the "true cause" of a failed
match in a MatchException, perhaps have MatchException be an interface
implemented by (subtypes of) ICCE and NPE, which compilers/runtimes and
future versions of the spec could add additional subtypes to later?
That way, exceptions thrown by matching would be consistent ("a subtype of
MatchException" rather than "an NPE or ICCE or ME"), and the spec would
have more flexibility to specify another top-level matching exception in
the future (and implementers could more easily specify their own diagnosis
logic) without breaking existing error handling, which also wouldn't have
to use an overly general catch block (catch all MEs and sometimes rethrow)
or parse exception descriptions (like a helpful-NPEs analogue) to rely a
more useful message to a developer or user.
Specifically using an interface would avoid needing to make all NPEs and
ICCEs into MatchExceptions (and potentially trigger false positive
catches), only producing match-based subtypes of these. Admittedly, that
relies on being able to specify a catch for an interface type with no
relation to Throwable, which may be too big of a change for consideration.
More information about the amber-dev
mailing list