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.arbou...@oracle.com>
To: Alex Buckley <alex.buck...@oracle.com>, amber-spec-experts
<amber-spec-experts@openjdk.java.net>
Cc: Stephan Herrmann <stephan.herrm...@berlin.de>
Date: 03/21/2019 06:35 AM
Subject: Re: Switch expressions spec
Sent by: "amber-spec-experts"
<amber-spec-experts-boun...@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@oracle.com_
<mailto:leonid.arbou...@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.r...@oracle.com>_
<mailto:john.r.r...@oracle.com> wrote:
On Mar 15, 2019, at 11:39 AM,
Alex Buckley
_<alex.buck...@oracle.com>_
<mailto:alex.buck...@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
