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.
OK, sure. This bothers me zero. Having an accessor (or dtor) throw is
already really^3 weird; having a program depend on which specific
exception it throws is really^32 weird. (In both cases, they still
throw an exception that you probably shouldn't be catching, with a clear
stack trace explaining where it went wrong.) Not a case to design the
language around.
Still not seeing any "destruction" here.
