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

[Brian Goetz]

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/915c6028/attachment.htm>