Flow of control is what is critical in every application, and goto's allow you to break flow of control easily. That said, a lot of very stable systems used go

Flow of control is what is critical in every application, and goto's allow you to break flow of control easily. That said, a lot of very stable systems used goto's for very specific instances. For example, they would use it to short circuit the if/else/if/else for error handling, cleanup etc. But it was a goto within a single scope, e.g. within a single function. Of course, with that power comes the ability to cut off an important appendage, and in reality the "need" for a goto is really not a need, it is a lazy implementation detail. Usually what I found is people feeling the need to use goto often just didn't understand how to design or layout the system they were working on, or try to put to many unrelated code segments into a function. As other comments mention, the flow of control changing scope etc cause lead to all kinds of difficult debugging, memory leaks, crashes etc. So not generally a good idea. Smarter to use proper function scoping, return behavior and error codes. One of my early tasks as a C programmer, back in the early 90's, was taking a C program that had like only 4-5 functions (with thousands of lines of code) in it, and tons of goto's and cleaning it up to be a maintainable system. Engineers all hated that system because it ran fairly stable (somehow), but touching a single line of code could mean days of debugging. Starting over was easiest but took forever to get the functionality correct because of all the jumps to weird places that were not obvious behaviors. That was an unforgettable lesson for me.