> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Sent: Thursday, April 21, 2022 6:20:24 PM
> Subject: Re: [External] : Re: Record pattern and side effects
>>> We’ve already asked one of the questions on side effects (though not sure we
>>> agreed on the answer): what if the dtor throws? The working story is that
>>> the
>>> exception is wrapped in a MatchException. (I know you don’t like this, but
>>> let’s not rehash the same arguments.)
>> Wrapping exceptions into a MatchException destroy any idea of refactoring
>> from a
>> cascade of if ... instanceof to a switch.
>> I think refactoring is a use case we should support.
> Wrapping exceptions thrown from dtors does not affect refactoring.
> If I have:
> if (x instanceof D(P)) A;
> else if (x instanceof D(Q)) B;
> else C;
> and I refactor to
> switch (x) {
> case D(P): A; break;
> case D(Q): B; break;
> default: C
> }
> Let's imagine that dtor D throws. The wrapping happens when a dtor/accessor is
> invoked _implicitly_ as a result of evaluating a pattern match. In both cases,
> we will wrap the thrown exception and throw MatchException. In this way, both
> instanceof and switch are "clients of" pattern matching, and it is pattern
> matching that throws.
> I don't see any destruction here.
I'm thinking about the refactoring from a code using accessors to a code using
a deconstructor.
By example, IDEs may propose to refactor this code
if (x instanceof D d) A(d.p()); else B;
to
if (x instanceof D(P p)) A(p); else B;
or vice versa
If you wraps deconstructor exceptions, but not accessor exceptions you have
mismatch.
And as i said earlier, there is also the issue with a deconstructor calling
another deconstructor (like your example with super), you may wrap a
MatchException into a MatchException.
Rémi
