Enum: difference of behaviour between exhaustive switch vs. using default:
Jean-Noël Rouvignac
jean-noel.rouvignac at pingidentity.com
Wed Dec 11 17:43:13 UTC 2024
Thank you all!
I agree with Remi, the problem no longer exists when using a switch
expression.
I thought I could not do it with our (obviously more contrived) code, but I
have managed to do it in the end.
That said, after sending the email, I actually wondered if this problem was
actually linked to the use of the "old switch" statement, and a possible
lack of understanding of the control flow?
I am ready to be told "we cannot fix it because of JLS rule 4.5.6.7" or
something like that.
Thank you again for taking a look at it,
Jean-Noël
On Wed, Dec 11, 2024 at 3:05 PM Angelos Bimpoudis <
angelos.bimpoudis at oracle.com> wrote:
> Filed it here: https://bugs.openjdk.org/browse/JDK-8345997
>
> Thank you for reaching out!
> Thx Remi for the minimized example as well.
> ------------------------------
> *From:* amber-dev <amber-dev-retn at openjdk.org> on behalf of Remi Forax <
> forax at univ-mlv.fr>
> *Sent:* 11 December 2024 13:44
> *To:* Gavin Bierman <gavin.bierman at oracle.com>
> *Cc:* Jean-Noël Rouvignac (ForgeRock) <
> jean-noel.rouvignac at pingidentity.com>; amber-dev <amber-dev at openjdk.org>
> *Subject:* Re: Enum: difference of behaviour between exhaustive switch
> vs. using default:
>
> Hello,
> I think it can be reduced to
>
> public enum Action { IGNORE, REJECT }
>
> private static void bad() {
> String s;
> switch (getAction()) {
> case IGNORE:
> s = "foo";
> break;
> case REJECT:
> throw new RuntimeException("REJECTED");
> };
> System.out.println(s); // <------- variable s might not have been initialized
> }
>
> private static void ok() {
> String s = switch (getAction()) {
> case IGNORE:
> yield "foo";
> case REJECT:
> throw new RuntimeException("REJECTED");
> };
> System.out.println(s); // ok !
> }
>
>
> so there is a bug in DA/DU rules and the workaround is to use a switch
> expression.
>
> Rémi
>
> ------------------------------
>
> *From: *"Gavin Bierman" <gavin.bierman at oracle.com>
> *To: *"Jean-Noël Rouvignac (ForgeRock)" <
> jean-noel.rouvignac at pingidentity.com>
> *Cc: *"amber-dev" <amber-dev at openjdk.org>
> *Sent: *Wednesday, December 11, 2024 1:20:15 PM
> *Subject: *Re: Enum: difference of behaviour between exhaustive switch
> vs. using default:
>
> Could you file this as a bug, and I will take a look?
>
> Thanks,
> Gavin
>
> On 10 Dec 2024, at 16:10, Jean-Noël Rouvignac (ForgeRock) <
> jean-noel.rouvignac at pingidentity.com> wrote:
>
> Hello amber-dev experts!
>
> I am modernizing our codebase by making it use enhanced / exhaustive
> switches.
>
> In several places, I replaced `default: ` by `case
> THE_ONLY_UNUSED_ENUM_VALUE:`, except that I am hitting an unexpected
> difference in behaviour, at least from my point of view.
>
> I have reduced the code to the following reproducer (tested on the
> https://dev.java/playground/), where `main1()` compiles, but `main2()`
> does not. And yet, I am under the impression both should be equivalent?
>
> What do you think?
> Thanks a lot.
>
>
>
> import java.io.IOException;
>
> class Main {
> public enum Action { IGNORE, REJECT }
>
> public static void main(String[] args) {
> main1();
> main2();
> }
>
> private static void main1() {
> String s;
> try {
> s = getValue();
> } catch (IOException e) {
> switch (getAction()) {
> case IGNORE:
> return;
> default:
> throw new RuntimeException("REJECTED");
> }
> }
>
> System.out.println(s);
> }
>
> private static void main2() {
> String s;
> try {
> s = getValue();
> } catch (IOException e) {
> switch (getAction()) {
> case IGNORE:
> return;
> case REJECT: // <------------------- Fails compilation
> throw new RuntimeException("REJECTED");
> }
> }
>
> System.out.println(s); // <------- Main.java:40: error: variable s
> might not have been initialized
> }
>
> static Action getAction() {
> return Action.IGNORE;
> }
>
> static String getValue() throws IOException {
> return "SUCCESS";
> }
> }
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
>
>
>
--
<https://www.pingidentity.com/> <https://www.pingidentity.com/>[image: Ping
Identity] <https://www.pingidentity.com/>
Jean-Noel Rouvignac
Senior Principal Software Engineer
jean-noel.rouvignac at pingidentity.com
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
Connect with us:
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
<https://www.linkedin.com/company/21870>[image: LinkedIn logo]
<https://www.linkedin.com/company/21870>
<https://twitter.com/pingidentity>[image:
twitter logo] <https://twitter.com/pingidentity>
<https://www.facebook.com/pingidentitypage>[image: facebook logo]
<https://www.facebook.com/pingidentitypage>
<https://www.youtube.com/user/PingIdentityTV>[image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV>
<https://www.pingidentity.com/en/blog.html>[image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
To view our privacy policy, click here
<https://www.pingidentity.com/en/legal/privacy.html>
To stop receiving these emails, click here
<https://4.pingidentity.com/PreferenceCenter.html>
--
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241211/3b492a45/attachment-0001.htm>
More information about the amber-dev
mailing list