[External] : Re: Remainder in pattern matching

Brian Goetz brian.goetz at oracle.com
Wed Mar 30 18:38:29 UTC 2022


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220330/283c457c/attachment.htm>


More information about the amber-spec-experts mailing list