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