Switch expressions spec

Alex Buckley alex.buckley at oracle.com
Thu Mar 21 19:16:23 UTC 2019


Leonid, thanks for checking JCK12, and for looking ahead to JCK13.

Alex

On 3/21/2019 8:25 AM, Leonid Arbuzov wrote:
> Hi Manoj,
>
> Thanks for the example.
> The  JCK12 doesn't have this particular testcase and can add it in the
> next release.
>
> Regards,
> -leonid
>
> On 3/20/2019 8:07 PM, Manoj Palat wrote:
>>
>> Hi Leonid,
>> The original query was based on this case:
>>
>>
>> Consider the following code:
>> public class X {
>> @SuppressWarnings("preview")
>> public static int foo(int i) throws MyException {
>> int v = switch (i) {
>> default -> throw new MyException(); // no error?
>> };
>> return v;
>> }
>> public static void main(String argv[]) {
>> try {
>> System.out.println(X.foo(1));
>> } catch (MyException e) {
>> System.out.println("Exception thrown as expected");
>> }
>> }
>> }
>> class MyException extends Exception {
>> private static final long serialVersionUID = 3461899582505930473L;
>> }
>>
>> As per spec, JLS 15.28.1
>>
>> It is a compile-time error if a switch expression has no result
>> expressions.
>> but javac (12) does not flag an error.
>>
>> Regards,
>> Manoj
>>
>>
>> Inactive hide details for Leonid Arbuzov ---03/21/2019 06:35:33
>> AM---Hi Alex, There are negative tests with missed result expreLeonid
>> Arbuzov ---03/21/2019 06:35:33 AM---Hi Alex, There are negative tests
>> with missed result expressions:
>>
>> From: Leonid Arbuzov <leonid.arbouzov at oracle.com>
>> To: Alex Buckley <alex.buckley at oracle.com>, amber-spec-experts
>> <amber-spec-experts at openjdk.java.net>
>> Cc: Stephan Herrmann <stephan.herrmann at berlin.de>
>> Date: 03/21/2019 06:35 AM
>> Subject: Re: Switch expressions spec
>> Sent by: "amber-spec-experts"
>> <amber-spec-experts-bounces at openjdk.java.net>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> Hi Alex,
>>
>> There are negative tests with missed result expressions:
>>
>>         int a = switch (selectorExpr) {
>>            case 0 -> 1;
>>            case 1 -> 1;
>>            default -> ;
>>        };
>>         int a = switch (selectorExpr) {
>>            case 0 -> { break 1; }
>>            case 1 -> { break 1; }
>>            default -> { fun(); }
>>        };
>>
>> If you meant no result expressions at all then I couldn't find such
>> test yet.
>> It can be added in JCK13.
>>
>> Thanks,
>> Leonid
>>
>> On 3/19/2019 5:28 PM, Alex Buckley wrote:
>>
>>         Hi Leonid,
>>
>>         So there are no negative tests that check what happens if a
>>         switch expression has no result expressions?
>>
>>         Alex
>>
>>         On 3/19/2019 5:24 PM, _leonid.arbouzov at oracle.com_
>>         <mailto:leonid.arbouzov at oracle.com> wrote:
>>                 There are tests on switch expression with cases that
>>                 throwing exception,
>>                 causing division by zero, index out of range, etc.
>>                 These are all positive tests i.e. compile fine.
>>
>>                 Thanks,
>>                 Leonid
>>
>>
>>                 On 3/15/19 1:20 PM, Alex Buckley wrote:
>>                         OK, we intend at least one result expression
>>                         to be required, so the
>>                         spec is correct as is.
>>
>>                         (I should have been clearer that my belief was
>>                         about the intent of the
>>                         spec, rather than about how I personally think
>>                         completion should occur.)
>>
>>                         Manoj didn't say what javac build he is
>>                         testing with, but this is a
>>                         substantial discrepancy between compiler and
>>                         spec. I hope that Leonid
>>                         Arbouzov (cc'd) can tell us what conformance
>>                         tests exist in this area.
>>
>>                         Alex
>>
>>                         On 3/15/2019 12:09 PM, Brian Goetz wrote:
>>                                 At the same time, we also reaffirmed
>>                                 our choice to _not_ allow throw
>>                                 from one half of a conditional:
>>
>>                                      int x = foo ? 3 : throw new
>>                                 FooException()
>>
>>                                 But John has this right — the high
>>                                 order bit is that every expression
>>                                 should have a defined normal
>>                                 completion, and a type, even if
>>                                 computing sub-expressions (or in this
>>                                 case, sub-statements) might
>>                                 throw.  And without at least one arm
>>                                 yielding a value, it would be
>>                                 impossible to infer the type of the
>>                                 expression.
>>                                         On Mar 15, 2019, at 3:01 PM,
>>                                         John Rose
>>                                         _<john.r.rose at oracle.com>_
>>                                         <mailto:john.r.rose at oracle.com> wrote:
>>
>>
>>                                         On Mar 15, 2019, at 11:39 AM,
>>                                         Alex Buckley
>>                                         _<alex.buckley at oracle.com>_
>>                                         <mailto:alex.buckley at oracle.com>
>>                                         wrote:
>>
>>                                                 In a switch
>>                                                 expression, I believe
>>                                                 it should be legal for
>>                                                 every
>>                                                 `case`/`default` arm
>>                                                 to complete abruptly
>>                                                 _for a reason other than
>>                                                 a break with value_.
>>                                         My reading of Gavin's draft is
>>                                         that he is doing something very
>>                                         subtle there, which is to
>>                                         retain an existing feature in
>>                                         the language
>>                                         that an expression always has
>>                                         a defined normal completion.
>>
>>                                         We also don't have expressions
>>                                         of the form "throw e". Allowing
>>                                         a switch expression to
>>                                         complete without a value on
>>                                         *every* arm
>>                                         raises the same question as
>>                                         "throw e" as an expression.
>>                                         How do
>>                                         you type "f(throw e)"?  If you
>>                                         can answer that, then you can
>>                                         also
>>                                         have switch expressions that
>>                                         refuse to break with any values.
>>
>>                                         BTW, if an expression has a
>>                                         defined normal completion, it
>>                                         also
>>                                         has a possible type.  By
>>                                         possible type I mean at least
>>                                         one correct
>>                                         typing (poly-expressions can
>>                                         have many).  So one obvious
>>                                         result of Gavin's draft is
>>                                         that you derive possible types
>>                                         from
>>                                         the arms of the switch
>>                                         expression that break with
>>                                         values.
>>
>>                                         But the root requirement, I
>>                                         think, is to preserve the
>>                                         possible
>>                                         normal normal of every
>>                                         expression.
>>
>>                                         "What about some form of
>>                                         1/0?"  That's a good question.
>>                                         What about it?  It completes
>>                                         normally with a type of int.
>>                                         Dynamically, the normal
>>                                         completion is never taken.
>>                                         Gavin might call that a
>>                                         "notional normal completion"
>>                                         (I like that word) provided to
>>                                         uphold the general principle
>>                                         even where static analysis
>>                                         proves that the Turing machine
>>                                         fails to return normally.
>>
>>                                         — John
>>
>>


More information about the amber-spec-experts mailing list