Why goto is not recommended to use in programs

Byron Whitlock Byron Whitlock Jumping out of nested loops are the only instance I have used goto statements. Even then, I refactor my code to simply return early when possible.

I know this is an old post, but I thought I'd add one more use for goto. In SQR goto is commonly used as a 'continue' in a loop. Many database languages don't have continues in the language so they put a goto at the end of the loop and call it if they need to 'continue'. More accurate to say because they can easily lead to spaghetti code if not used wisely.

Sometimes it is actually the cleanest, DRYest way of doing things, especially in languages that don't focus on structured programming, as I've just discovered when trying to make a loop continue in T-SQL. A return can be used instead of goto to jump out of nested loops.

For example, extract the nested loops into a new function and return from there when the condition that triggers the goto is satisfied. I only see goto being used only to get an extra bit of performance — mljrg. Show 8 more comments. What if there are some automatic objects constructed on the stack, which are local inside the loop? Goto will jump to some other place, jumping over the end of the blocks, where the destructors for these objects are called.

In most cases, it won't do anything bad. But there are cases where it WILL do, including losing user's data etc. SasQ: The compiler is responsible for ensuring that the actual "jmp" instruction generated for the goto is preceded by whatever code would be necessary to get rid of inner scope variables. It's not true that goto can jump between functions. TrevorBoydSmith- You're right, I must have been thinking about longjmp same problematic concept, different interface.

Show 4 more comments. JaredPar JaredPar k gold badges silver badges bronze badges. Ken Bloom Ken Bloom Gerry: that's a good one. I hadn't thought of that. Actually, with the goto he used to goto a subroutine of some sort , raptors should attack him. There are more implications, and you are right to mention it. Show 2 more comments. Did you google the issue?

The founder of the anti-goto movement is Edsger Dijskstra with his legendary "Goto Considered Harmful" To get you started you can goto ha ha! John Smith John Smith Ironically, he actually tolerated far more GOTO than programmers today. Ole V. This is more concise and easier to understand than the preceding version of the code.

It says what it means. It expresses the idea with less conceptual overhead. C programs must detect and handle errors. When an error occurs, it is important to bail out while still cleaning up any dangling resources. The code should close any open files and free any allocated memory. Suppose your task is to write a C program that reads lines of text from a file.

Each line is supposed to contain three floating point numbers. And no matter what, your program should always clean up by freeing memory and closing the input file. One way to implement this program is shown here. It is a correct implementation that meets all the requirements.

There is something unsavory about this code. It repeats cleanup logic: three places free memory allocated to line , and two places close infile. Imagine some day you add another resource that needs cleanup at each stopping point: perhaps an output file to be closed, or another block of memory to be freed. You would have to study the code and find all the error cases and insert cleanup logic to each case. There is a better way.

You guessed it — it involves goto. The idea is to have a single exit point for a function, located at the end, with all the cleanup located in one place. Here is how the same program looks when crafted this way. This code is easier to review. It is clear that no matter what, the line will be freed and the infile will be closed.

The error handling pattern ensures that line and infile always have defined values: either NULL or a valid pointer. The cleanup code closes infile only if it was open. It also takes advantage of the fact that free NULL is safe and has no effect. Again, imagine you want to add yet another resource that must be cleaned up.

This time, your task will be simpler. Whether the function succeeds or any of the error cases occur, you can sleep well, knowing your additional resource cleanup will be executed. In general, it is a good idea to avoid goto in most cases. Before using goto in a C program, ask yourself a few questions. Could this usage possibly create an unintentional loop? This is certainly not an exhaustive list. Code can get confusing very quickly when it takes arbitrary paths and jumps from place to place.

The more GOTOs in the same routine, the worse it gets. Debugging is enough of a challenge when code runs sequentially. When it jumps around as you are trying to step through it, debugging can become a nightmare. It is easy to get caught in an infinite loop if the goto point is above the goto call. This is almost guaranteed if there is no reliable escape from the code, such as a RETURN statement within a conditional statement.

It might be tempting to put a goto statement within a catch block. If there is an error, catch it, and then jump to a certain section of code that performs some recovery action, right? The problem with this is that if you don't cancel your catch and an error occurs later down the road after the goto point, it will be re-caught by the catch statement, and then you have the infinite loop problem again hint: always cancel your catch before performing recovery action.

If you do cancel the catch, however, then you've just cancelled the handler for your mainline code, and then you jump right back into it. Additional errors will not be handled. Unless you have a different catch block somewhere in the routine, or maybe one somewhere at a higher scope level. When that happens, good luck debugging see "Confusing Code" above.