[External] : Re: Record pattern and side effects

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220422/2a2c30f0/attachment-0001.htm>