Switch expressions spec

Leonid Arbuzov leonid.arbouzov at oracle.com
Thu Mar 21 15:25:22 UTC 2019


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