The infamous "goto"

The infamous "goto"

The goto keyword has been present in programming languages from the beginning. Indeed, goto was the genesis of program control in assembly language: "if condition A, then jump here, otherwise jump there." If you read the assembly code that is ultimately generated by virtually any compiler, you'll see that program control contains many jumps. However, goto jumps at the source-code level, and that's what brought it into disrepute. If a program will always jump from one point to another, isn't there some way to reorganize the code so the flow of control is not so jumpy? goto fell into true disfavor with the publication of the famous "Goto considered harmful" paper by Edsger Dijkstra, and since then goto-bashing has been a popular sport, with advocates of the cast-out keyword scurrying for cover.

As is typical in situations like this, the middle ground is the most fruitful. The problem is not the use of goto but the overuse of goto, and in rare situations goto is the best way to structure control flow.

Although goto is a reserved word in Java, it is not used in the language; Java has no goto. However, it does have something that looks a bit like a jump tied in with the break and continue keywords. It's not a jump but rather a way to break out of an iteration statement. The reason it's often thrown in with discussions of goto is because it uses the same mechanism: a label.

A label is an identifier followed by a colon, like this:

The only place a label is useful in Java is right before an iteration statement. And that means right before - it does no good to put any other statement between the label and the iteration. And the sole reason to put a label before an iteration is if you're going to nest another iteration or a switch inside it. That's because the break and continue keywords will normally interrupt only the current loop, but when used with a label they'll interrupt the loops up to where the label exists:

label1:
outer-iteration

In case 1, the break breaks out of the inner iteration and you end up in the outer iteration. In case 2, the continue moves back to the beginning of the inner iteration. But in case 3, the continue label1 breaks out of the inner iteration and the outer iteration, all the way back to label1. Then it does in fact continue the iteration, but starting at the outer iteration. In case 4, the break label1 also breaks all the way out to label1, but it does not re-enter the iteration. It actually does break out of both iterations.

Here is an example using for loops:

This uses the prt( ) method that has been defined in the other examples.

Note that break breaks out of the for loop, and that the increment-expression doesn't occur until the end of the pass through the for loop. Since break skips the increment expression, the increment is performed directly in the case of i == 3. The continue outer statement in the case of I == 7 also goes to the top of the loop and also skips the increment, so it too is incremented directly.

Here is the output:

If not for the break outer statement, there would be no way to get out of the outer loop from within an inner loop, since break by itself can break out of only the innermost loop. (The same is true for continue.)

Of course, in the cases where breaking out of a loop will also exit the method, you can simply use a return.

Here is a demonstration of labeled break and continue statements with while loops:

The same rules hold true for while:

A plain continue goes to the top of the innermost loop and continues.

A labeled continue goes to the label and re-enters the loop right after that label.

A break "drops out of the bottom" of the loop.

A labeled break drops out of the bottom of the end of the loop denoted by the label.

The output of this method makes it clear:

It's important to remember that the only reason to use labels in Java is when you have nested loops and you want to break or continue through more than one nested level.

In Dijkstra's "goto considered harmful" paper, what he specifically objected to was the labels, not the goto. He observed that the number of bugs seems to increase with the number of labels in a program. Labels and gotos make programs difficult to analyze statically, since it introduces cycles in the program execution graph. Note that Java labels don't suffer from this problem, since they are constrained in their placement and can't be used to transfer control in an ad hoc manner. It's also interesting to note that this is a case where a language feature is made more useful by restricting the power of the statement.