Uniform Handling of failure in switch -- Exhaustiveness on Exceptions?

[David Alayachew]

Hello Brian,

Thank you for your response!

Yet again, I did not think things through. I was only thinking of switches
being inside of methods.

But switches are expressions now, so they can be anywhere that we put an
expression.

So, I could put them on an instance field or a static field. How could we
handle that if the switch wasn't total?

Yes, what you say about method boundaries not only makes sense, but is
practically required because switch is an expression.

Thank you for your time and help!
David Alayachew


On Thu, Jan 4, 2024, 1:59 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> There's another piece of the answer here as well, which is the existing
> boundaries for type-checking checked exceptions.  And that existing
> boundary is solely method boundaries.  (Lambdas are methods.)
>
> A method can be declared to throw a set of checked exceptions; the only
> place we check for "you can't throw X here" is at the top level of a
> method.  (What exceptions might be thrown from the top level may bubble up
> from more deeply nested blocks within a top-level statement, through flow
> analysis.)
>
> The current proposal does not propose to change that; we are not making
> switches a boundary where we do method-style exception checking (we'd have
> to put a `throws` clause on a switch if we did.)
>
> On 1/1/2024 2:37 AM, David Alayachew wrote:
>
> Hello,
>
> Thank you for your response!
>
> Yes, this makes a lot of sense, and I figured it would be the case. But
> the article (surprisingly) didn't address that point at all. Likely because
> just broaching the topic of exceptions in switch was a task on its own, and
> this subject will come later.
>
> I also appreciate the set theory formula at the end. You also posted that
> in the other thread, and I still plan to respond to that once I get the
> chance.
>
> Thank you for your time and help!
> David Alayachew
>
> On Mon, Jan 1, 2024 at 2:27 AM Holo The Sage Wolf <holo3146 at gmail.com>
> wrote:
>
>> Checked exceptions will remain totally checked.
>>
>> Given a function f, let checkF be the set of checked exceptions, then the
>> expression:
>>
>> switch(root(args)) {
>>     case branch0 -> do0(args);
>>     case branch1 -> do1(args);
>>     ...
>>     case branch1 -> doN(args);
>>     case throws fBranch0 -> handle0(args);
>>     case throws fBranch0 -> handle1(args);
>>     ...
>>     case throws fBranch0 -> handleM(args);
>> }
>>
>> Will have the following set of checked exceptions:
>>
>>    (checkRoot - {fBranch0, ... fBranchM}) + checkDo0 + ... + checkDoN +
>> checkHandle0 + ... + checkHandleM
>>
>> Where minus is set difference and plus is union
>>
>> On Mon, 1 Jan 2024, 09:12 David Alayachew, <davidalayachew at gmail.com>
>> wrote:
>>
>>> Hello Amber Dev Team,
>>>
>>> I read Brian Goetz's "Case Effect on Switch" (looks like it recently got
>>> renamed to "Uniform handling of failure in switch"), and I have a quick
>>> question.
>>>
>>> I think it's cool to bring error handling into switch, but will we still
>>> get the exhaustiveness/totality on checked exceptions that we are used to
>>> on the try catch side?
>>>
>>> I feel like it would be weird and unintuitive if it didn't, since switch
>>> expressions already give us exhaustiveness/totality, and that's basically
>>> the biggest reason to use a switch expression in the first place. Leaving
>>> it out for exceptions would just feel mean. Plus, having this feature would
>>> really help with clarifying intent and with readability.
>>>
>>> Thank you for your time and help!
>>> David Alayachew
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240104/34bfc366/attachment-0001.htm>