Most programming languages have flow control features of some kind. Yeah, I know there are some languages that lack them, for example early programmable shader languages, some macro languages, and I think some programmable calculators just run a program straight through from beginning to end. But by and large, programming languages provide ways to jump around within the code and write decision-making logic.
Fairly early on, people realised that the only things you really need for flow control are a way to make a comparison, and a way to conditionally jump to another point in the program based on the result of a comparison. On top of these primitives, you can build flow structures that are as complex as you like. If you look at the native machine code that computers run, you can see that this has really been taken to heart: most CPUs provide a way to store the result of a comparison and one or more conditional jump instructions. Early programming languages like BASIC and Fortran had flow control based entirely on these primitives, too. If you learned to program on an 8-bit personal computer, you’ll no doubt remember writing statements like “IF condition THEN GOTO line” all the time.
But in 1968, this form of flow control was about to get a major setback (at least in high-level languages), because Edsger Dijkstra had written what was to become a highly influential letter entitled “A Case Against the Goto Statement”. You probably don’t know it by this name, though, because it was published in CACM under the title “ Go To Statement Considered Harmful” (Niklaus Wirth, a CACM editor at the time, changed the title for publication). This letter criticised the goto statement and the form of flow control associated with it, instead advocating structured programming.
Most modern high-level programming languages are designed with structured programming in mind: simple statements can be grouped into compound statements (with begin and end delimiters in Pascal, or with curly braces in C or Java), and flow control is based around these compound statements. For example, and if statement can be used to conditionally skip over a compound statement. Essentially, compound statements are the basic building block from which you build your structured code. Poor goto has survived to varying degrees: it’s present but rarely used in C and Pascal, and is a reserved word with no function in Java, for example.
The crusade against the goto statement has continued unabated. Most programming lecturers will advise against its use, or neglect to mention its existence. Programs that make use of it are referred to as “spaghetti code” because flow control can conceivable jump from any given point to any other given point. This can make code difficult to understand, debug or modify. However, in spite of this, I think Dijkstra’s message is being largely ignored.
You see, the beauty of structured code, and part of what makes it easy to understand (and consequently easy to debug and modify), is that code blocks only have a single entry point and a single exit point – program flow enters the block at the beginning, continues through it linearly, and leaves it at the end. All flow control statements operate on entire blocks – an if statement skips an entire block if the condition is not met. The goto statement obviously violates this principle, as program flow can be made to jump to an arbitrary point. And that’s why Dijkstra criticised it: because it causes program flow to deviate from the program’s structure. However, despite the ongoing crusade against goto, several other flow control structures that effectively do the same thing are being encouraged. These include loop control statements (continue and break), C-style return statements and exceptions. Let’s have a look at each of them.
First up, let’s think about loops. A loop will have some kind of condition that must be maintained in order for it to run, and a block of code that runs while the condition is maintained. Now this block, like any other block of code in a structured program, will have a natural entry point at the top and an exit point at the bottom. The loop itself has an exit point after the loop condition is evaluated. But when you add a continue statement, you’re adding another exit point to the loop body. You can no longer say that the loop body will be entered at the top and left at the bottom. In fact, continue may as well just be shorthand for doing a goto that jumps to the end of the loop body. A break statement is slightly worse: it’s like a goto that jumps to a point just outside the loop – it’s not only adding an additional exit point to the loop body, but adding an exit point to the loop itself!
C-style return statements are similar: they add exit points to functions (effectively a goto that jumps to the end of the function body). I do realise that there isn’t really much you can do about them, though – there isn’t any other way to return a value from a function. The best you can really do is to only ever place one return statement in a function, and to place it at the end of the body. (Pascal lets you return a value by assigning to the name of the function, so there’s no excuse there.)
Now neither of these are really any better or worse than goto statements. They’re just like shorthand goto statements where the destination is implied. If you use them, fair enough – just be aware of the consequences, and think twice before you criticise goto again, because your code is starting to look like spaghetti, too.
But exceptions are the worst of all. Exceptions are like a goto where you don’t know the destination! Think about it: throwing an exception could jump to somewhere in the same function, or somewhere up the call stack. You just don’t know where it will land (The only thing they can’t do that a goto can is to jump backwards within a code block.) Use of exceptions means you don’t know whether a function call will return, or jump somewhere else. Worst of all, in C++ simply unwinding an object could cause an exception to be thrown, which will most likely lead to a memory leak.
To deal with exceptions properly, you need to write ugly code. Languages like Java help you out a bit with finally blocks. But you still have to remember to wrap anything that needs cleaning up in a try block and to place the clean-up code in the corresponding finally block – the language can’t make you code properly. So now you’re code is littered with try…finally constructs.
Of course, the C++ way has to be the ugliest: RAII. If you need to clean something up, you need to make a small class with the thing that needs to be cleaned up in the constructor, and the clean-up code in the destructor, and remember to be very careful to ensure you won’t throw an exception from the destructor, because then you’re really screwed. Now create an instance of this class and make sure it’s unwound at the point where you need the clean-up to occur. Now your code is littered with these small classes that are only really there in case an exception is thrown. You also can’t see the program flow properly, because it will be jumping to all these little destructors. And you want to hope you don’t need to try stepping through it in a debugger, because that’s an absolute nightmare.
There’s one place that exceptions are even more evil, if that’s possible: Objective-C++. There is no proper way to deal with exceptions in Objective-C++ because C++ frames will not be properly unwound when an Objective-C exception is thrown. (Objective-C exceptions are generally only thrown in truly exceptional circumstances, so it isn’t such a big problem in practice, but that’s beside the point.)
So why don’t we bring back goto? We’re doing all the things that make it harmful – we’re just kidding ourselves by refusing to call it what it is.
