How to break a while loop inside a switch statement?

[howachen]

while ( ... ) {

switch (test) {

case 'e':
// HOW TO BREAK THE WHILE LOOP ? I CAN'T USE THE "BREAK" HERE
break;

default:
...

break;
}
}

 

[Andrew Tyson]

while ( ... ) {

switch (test) {

case 'e':
// HOW TO BREAK THE WHILE LOOP ? I CAN'T USE THE "BREAK" HERE
break;

default:
...

break;
}
}

FOO_BAR : while() {
switch (blah)
case 'e':
break FOO_BAR;
...
}

 

[Luc The Perverse]

FOO_BAR : while() {
switch (blah)
case 'e':
break FOO_BAR;

HUH? What's this?

Is this for real?

If it is, I would like to take a second to rant about all the damn times I
have made worthless boolean variables to hold exit, fail, "error" or bad
values simply as an exit condition for a nested loop.

And I am left to wonder . . . how many other things do I not know that I
don't know?

 

[opalpa]

HUH? What's this?

Is this for real?

If it is, I would like to take a second to rant about all the damn times I
have made worthless boolean variables to hold exit, fail, "error" or bad
values simply as an exit condition for a nested loop.

It is for real.

I prefer, and recommend, boolean variables anyway.

Cheers.

 

[Timo Stamm]

HUH? What's this?

It's a label. You can use labels for loop constructs:

label: while(true) {}
label: for (;;
label: do {} while (true);

And for blocks:

a: {
// ...
b: {
// ...
break a;
}
// ...
}

Blocks are quite interesting. You can use them to structure long method
bodies (local variables are block-local) and you can even nest them and
use labels to exit them.

But I haven't found any practical use for them yet. I guess it's always
better to use a separate method instead of a block.


Timo

 

[PSUnderwood]

Yup. It's a labeled break, and it's a wonderful thing. You can do a
similar thing with continue, if you're so inclined.

Have a nice rant.

Regards,
Paul

 

[Patricia Shanahan]

HUH? What's this?

Is this for real?

If it is, I would like to take a second to rant about all the damn times I
have made worthless boolean variables to hold exit, fail, "error" or bad
values simply as an exit condition for a nested loop.

The question of which is more readable, labeled break or boolean
controls, depends on the situation and is highly arguable. I'm aware of
the labeled break, but usually prefer a boolean. In particular, the
boolean makes it easy to self-document the reason for stopping:

boolean widgetFound = false;
while(!widgetFound){
switch(blah)
case e:
widgetFound = true;
break;
....

And I am left to wonder . . . how many other things do I not know that I
don't know?

That is one of the reasons I hang out in this newsgroup, and often read
the other responses even if I think I know the answer.

Patricia

 

[Juha Laiho]

HUH? What's this?

As others have told, a labeled statement, and break from a labeled block.

Is this for real?

This should be a good place to start your research:
http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.7

And I am left to wonder . . . how many other things do I not know that I
don't know?

You'll find out at least some of that by reading through the JLS (something
I should do myself, too..).

 

[Chris Uppal]

If it is, I would like to take a second to rant about all the damn times I
have made worthless boolean variables to hold exit, fail, "error" or bad
values simply as an exit condition for a nested loop.

Personally, I have never used the feature, and have only ever seen it used very
rarely. Nor do I (ever) use boolean flags to control loop exit conditions and
the like.

IMO both should be avoided except in very special circumstances.

-- chris

 

[Luc The Perverse]

Personally, I have never used the feature, and have only ever seen it used
very
rarely. Nor do I (ever) use boolean flags to control loop exit conditions
and
the like.

IMO both should be avoided except in very special circumstances.

-- chris

You have never needed out of a nested loop?

 

[Chris Uppal]

You have never needed out of a nested loop?

Not that I remember, no. Single level break and continue, plus return have
always been enough to me without spoiling the code structure. And I've worked
in lots of domains, so I don't think that it's just a case of "it's not needed
for <such and such> code".

That is, of course, only as far as I can remember. I'm not claiming that there
may not have been exception circumstances when I would have used a targeted
break if I had one available, but I don't think they've been at all common. I
grew up with C where there is no such feature, so maybe I've just learned to
structure my code with little reliance on syntactically nested loops (which I
find confusing anyway).

-- chris

 

[AndrewMcDonagh]

You have never needed out of a nested loop?

No you dont have to....

By 'separating Query from Modification'
http://www.refactoring.com/catalog/separateQueryFromModifier.html

and/or combined with

'Spilt loop'
http://www.refactoring.com/catalog/splitLoop.html

 

[lordy]

No you dont have to....

By 'separating Query from Modification'
http://www.refactoring.com/catalog/separateQueryFromModifier.html

and/or combined with

'Spilt loop'
http://www.refactoring.com/catalog/splitLoop.html

There are times when a simple nested loop of 2-4ish levels is easier to
read and maintain than having each loop level in its own method. The
latter might often require extra fields or parameters to be introduced
to pass state between the loop levels. More readable to just have nested
loops. Not always but mostly IMO.

Also nested loops may occur where there is a lot of CPU intensive
processing. In such a case it would be bad to introduce extra method
calls, and replace local variables with fields and/or parameters just
because you didn't want to do 'break LABEL'

Lordy

 

[Luc The Perverse]

There are times when a simple nested loop of 2-4ish levels is easier to
read and maintain than having each loop level in its own method. The
latter might often require extra fields or parameters to be introduced
to pass state between the loop levels. More readable to just have nested
loops. Not always but mostly IMO.

Also nested loops may occur where there is a lot of CPU intensive
processing. In such a case it would be bad to introduce extra method
calls, and replace local variables with fields and/or parameters just
because you didn't want to do 'break LABEL'

Lordy

I HAVE used try catch blocks to exit before - but the overhead of such a
thing is absurd (AFAIK).

 

[EJP]

You have never needed out of a nested loop?

Back when I was writing interpreters and cycles were critical we did it
like this:

while (condition)
{
// ...
switch (opcode)
{
case 0:
// ..
continue;
case 1:
// ..
continue:
case 2:
if (...)
break;
continue;
// ...
} // switch
// stuff at end of switch to be reached only via 'break'
} // while

 

[Chris Uppal]

Back when I was writing interpreters and cycles were critical we did it
like this:

while (condition)
{
// ...
switch (opcode)
{
case 0:
// ..
continue;
case 1:
// ..
continue:
case 2:
if (...)
break;
continue;
// ...
} // switch
// stuff at end of switch to be reached only via 'break'
} // while

I've used almost exactly that structure for that purpose too -- the only
difference was that I had a for (; loop around it rather than a condition at
the head of the loop. The "stuff at end of switch to be reached only via
'break'" was incrementing the instruction pointer, which wasn't wanted after
branch instructions.

-- chris

 

[steve]

You have never needed out of a nested loop?

[/QUOTE]
[/QUOTE]

there are those that believe that a loop is a "contract", and that if it
loops for a given amount, that it should always complete that amount.

Say as, opposed to being a loop for 20, but exiting at 10, personally i try
to use a flag variable & "while"

but there are those that use "try" catch to exit loops, and thrown
exceptions.

and vary rarely , like in 5 years of java , I will admit to 2 pieces of my
code having exit labels
but that was only to trap a fairly difficult validation of user data.

So generally I consider i'm not completely insane.