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