All too often, goto statements are used to patch up wooly thinking or an ill-defined algorithm. However, there are situations where the use of the goto statement is justified. For example, if there is an emergency situation in a process-control application, is it really better to set a flag and check it later in the algorithm than to take a direct route via a goto? The “goto statement should not be used” rule is now advisory rather than required, and an additional two rules narrow down the circumstances under which it is acceptable:
The goto statement shall jump to a label declared later in the same function.
Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.
Nooooooooooo, yee shall not pass goto, for if thou do'eth thou surely be cast into thee depths of eternity, lost and abandoned it time, never to return.
in case of an emergency you can use goto but you must not expect the system in a defined state thereafter. Even a graceful degradation is doubtful at best.
If you detect a real emergency (the "Houston we got a problem" kind) why not call the emergencyHandler() ?
And return afterwards and continue?
I involved myself in this conversation way-back-when on the electro-tech forum, regarding state machines:
In it, me and another user (MikeMI) have a discussion regarding state machines and whether using IF-THEN logic and GOTOs for such implementations (vs a switch-case construct) is better, worse, or...?
Anyhow - he posted an image of an implementation of such a state machine:
Anyhow - I found that example of using IF-THEN logic and GOTO to implement such logic to be very interesting; it wasn't difficult to follow, and made me appreciate GOTO a bit more (I grew up on Microsoft BASIC on a TRS-80 Color Computer - GOTO was in my blood for a long time, until it was excised during my first professional software development gig).
I now think of it as one of those tools that one should be aware of, but should only use when the situation absolutely warrants it - breaking out of deeply nested logic is one potential area (provided you don't break a stack or something); though I would perhaps do some investigation into that logic to see if maybe there is some way to make it more workable without requiring such a sledgehammer measure.
...and a second potential situation would be this example of a state machine.
I have also seen an instance (when I worked at a place that used a variant of COBOL called DB/C) where GOTO was used to jump out of (or into? it's been so long now) an error "trap" routine; but the developers there who worked in that system (I was only peripherally involved) made it explicit that such use was the -only- place that GOTO was allowed in the software they developed, and no where else.
weedpharma:
Maybe it belongs with the Irish Basic statement "come from".
Weedpharma
You obviously never programmed Fortran then. The basic looping construct specified a line number which would be the end of the loop and that line number could contain a regular statement, with no indication that the next statement to be executed was probably not the statement immediately below.
MorganS:
You obviously never programmed Fortran then. The basic looping construct specified a line number which would be the end of the loop and that line number could contain a regular statement, with no indication that the next statement to be executed was probably not the statement immediately below.
Not never programmed Fortran, just have forgotten absolutely every detail I once learnt!