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

[David Alayachew]

Oh wow, I never knew. Good to know, ty vm. And makes sense, ty vm.

On Fri, Jan 5, 2024 at 9:09 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> The interaction of field initializers and exceptions are already
> well-defined, there's nothing new here.  If e is an expression that can
> throw a checked exception, and e is used as an instance field initializer,
> then all constructors must be declared to throw that checked exception.
> Whether the initializer is a switch or a method call makes no difference.
> The important thing is that (a) switch expressions either always evaluate
> to a value or complete abruptly (which has been true for switch expressions
> since they were introduced) and (b) that we statically know which checked
> exceptions an expression may throw (the analysis discussed here covers that
> for switches.)
>
> On 1/4/2024 8:34 PM, David Alayachew wrote:
>
> 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/20240105/cb00053a/attachment.htm>