I don't use a lot of switches so I hadn't realized this but:
this is invalid:
if (1==1) {
String s;
} else {
s = "1";
}
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
On 5/24/2023 8:15 AM, e.d.pro...@gmail.com wrote:
I don't use a lot of switches so I hadn't realized this but:
this is invalid:
if (1==1) {
String s;
} else {
s = "1";
}
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
The entire switch sort of has to be a single scope due to
fall through (no break) being valid.
I don't use a lot of switches so I hadn't realized this but:
this is invalid:
if (1==1) {
String s;
} else {
s = "1";
}
but this is fine:The entire switch sort of has to be a single scope due to
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
fall through (no break) being valid.
Arne
I guess it makes sense. You could call it a soft scope? In the ifI don't use a lot of switches so I hadn't realized this but:The entire switch sort of has to be a single scope due to
this is invalid:
if (1==1) {
String s;
} else {
s = "1";
}
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
fall through (no break) being valid.
Arne
statement you get an undeclared variable error as it knows the if
block will never execute with the else condition. In the switch
statement it also will never execute both the declaration and the
assignment, unless you remove the break. Since the break it optional,
the compile sees it as one, though it also executes fine.
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
Am 24.05.23 um 14:15 schrieb e.d.pro...@gmail.com:
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
Shouldn't this be a problem too because the 2nd switch label bypasses
the initialization of s?
On 5/28/2023 7:31 AM, Marcel Mueller wrote:
Shouldn't this be a problem too because the 2nd switch label bypasses
the initialization of s?
The `case 1:' part *is* the initialization of `s'. There is a
*declaration* of `s' in the `case -1:' part, but the declaration
does nothing (here) to initialize the `s' reference.
If we added another case to the switch, say
default:
System.out.println(s);
break;
... the compiler would complain that `s' might be used without
being initialized, true. But the code as shown does not try
to retrieve any value from `s', so the compiler holds its peace.
There's really no mystery here at all. What e.d.programmer has
observed is simply that the block governed by `switch' is just
like any other block: A declaration within a block has scope
that runs from the declaration to the block end.
Am 24.05.23 um 14:15 schrieb e.d.pro...@gmail.com:
but this is fine:
switch (1) {
case -1:
String s;
break;
case 1:
s = "1";
break;
}
There's really no mystery here at all. What e.d.programmer has
observed is simply that the block governed by `switch' is just
like any other block: A declaration within a block has scope
that runs from the declaration to the block end. The fact that
this block is part of a `switch' does not change matters: a
block is a block is a block.
Am 28.05.23 um 14:36 schrieb Eric Sosman:
On 5/28/2023 7:31 AM, Marcel Mueller wrote:
Shouldn't this be a problem too because the 2nd switch label bypasses
the initialization of s?
The `case 1:' part *is* the initialization of `s'. There is a
*declaration* of `s' in the `case -1:' part, but the declaration
does nothing (here) to initialize the `s' reference.
If we added another case to the switch, say
default:
System.out.println(s);
break;
... the compiler would complain that `s' might be used without
being initialized, true. But the code as shown does not try
to retrieve any value from `s', so the compiler holds its peace.
So ist is only valid because of the optimization?
String s;
is a default constructor call.
s = "1";
is an assignment operator call.
I expected the latter to be invalid without the first (unless String is
a trivial type).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 28:02:25 |
Calls: | 8,717 |
Files: | 13,273 |
Messages: | 5,955,564 |