Another way to think about this is:
- If any of the code that the user actually wrote (the RHS of case
clauses, or guards on case labels) throws, then the switch throws that
- If any of the machinery of the switch dispatch throws, it throws
MatchException.
On 3/30/2022 2:12 PM, Dan Heidinga wrote:
The rules regarding NPE, ICCE and MatchException look reasonable to me.
As a separate but not-separate exception problem, we have to deal with at least
two additional sources of exceptions:
- A dtor / record acessor may throw an arbitrary exception in the course of
evaluating whether a case matches.
- User code in the switch may throw an arbitrary exception.
For the latter, this has always been handled by having the switch terminate
abruptly with the same exception, and we should continue to do this.
For the former, we surely do not want to swallow this exception (such an
exception indicates a bug). The choices here are to treat this the same way we
do with user code, throwing it out of the switch, or to wrap with
MatchException.
I prefer the latter -- wrapping with MatchException -- because the exception is thrown
from synthetic code between the user code and the ultimate thrower, which means the
pattern matching feature is mediating access to the thrower. I think we should handle
this as "if a pattern invoked from pattern matching completes abruptly by throwing
X, pattern matching completes abruptly with MatchException", because the specific X
is not a detail we want the user to bind to. (We don't want them to bind to anything,
but if they do, we want them to bind to the logical action, not the implementation
details.)
My intuition (and maybe I have the wrong mental model?) is that the
pattern matching calling a user written dtor / record accessor is akin
to calling a method. We don't wrap the exceptions thrown by methods
apart from some very narrow cases (ie: reflection), and I thought part
of reflection's behaviour was related to needing to ensure exceptions
(particularly checked ones) were converted to something explicitly
handled by the caller.
If the dtor / record accessor can declare they throw checked
exceptions, then I can kind of see the rationale for wrapping them.
Otherwise, it seems clearer to me to let them be thrown without
wrapping.
I don't think we expect users to explicitly handle MatchException when
using pattern matching so what does wrapping gain us here?
--Dan
