Error handling and multi loop exiting are permitted use cases of go-to.
this post was submitted on 07 Oct 2025
80 points (98.8% liked)
Programmer Humor
26891 readers
724 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Java doesn't allow goto, but specifically does have labels for labeled break/continue to support the multi-loop exiting case.
I imagine these two "structures" will always be implemented in C source through disciplined use of goto.
It's literally the only way to do this. Other ways include checking of loads of bools. That's slow.
In C maybe. In language that support proper recursion schemes, the apomorphism models the early-exit loop.
I also use it for avoiding recursive function calls. In theory, this will tell the compiler to just ditch the current stack and go back to the beginning of the function.
In civilized languages tail recursion takes care of this for you. 😁
gcc can do tail-call optimization in C, and sometimes in C++. It doesn't even have to be a recursive call, tho I do think it might depends on the calling convention.
Oh, cool! I did not know that.
IIRC, this is because gcc optimizes goto very well, or at least it did back in the day. It also is a genuinely workable solution for error handling in C.
Consider if you need to setup three things, do something with them, and then tear them down in reverse order. If there's an error on the second thing, you want to jump right to the part where you tear down the first thing. Using goto tends to make cleaner code for that in C compared to, say, nested conditionals.
It's beautiful
but how many COMEFROMs are there
Really nice combination of data and presentation.
~200000 in ~73 million isn’t so bad, right?
I'm pretty certain this has traumatized me.
Seems like it's mostly error handling, which makes total sense to me.
In a function with a lot of error conditions, where it also takes more than return <nonzero value> to report that error, the code would get very cluttered if you handle the errors inline.
Using goto in that case makes the normal case shorter and more readable, and if proper labels are used, it also becomes clear what happens in each error case.
Sure, you can do that with functions too, but it's much nicer staying in the same scope where the error occurred when reporting on it. Putting things in a function means thinking about what to pass, and presents extra resistance when you want to report extra info, because you have to change the function signature, etc.
Go-To's are just a primitive functions that dont isolate code, just use functions.
Not really. There are quite a few of structures you can make with gotos that can't directly be translated into functions. Sure, you can implement any functionality in any programming paradigm, but it might require much more work than to just replace goto with a function call.
In C, goto is basically a necessity though. There is really no good way of error handling.
Options:
- Using goto
void func(void *var) {
void * var2 = malloc();
if var == Null {
goto err;
}
do_something();
err:
free(var2);
}
- Early returns:
void func(void *var) {
void * var2 = malloc();
if var == Null {
free(var2);
return;
}
do_something();
free(var2);
}
- Skipping with conditionals:
void func(void *var) {
bool error = false;
void * var2 = malloc();
if var == Null {
error = true;
}
if !error {
do_domething()
}
free(var2);
}
- Early return + cleanup function.
void cleanup(void *var2) {
free(var2);
}
void func(void *var) {
void * var2 = malloc();
if var == Null {
cleanup(var2);
return;
}
cleanup(var2);
}
Option 1 is really the only reasonable option for large enough codebases.
Option 2 is bad because duplicate code means you might change the cleanup in one code path but not some other. Also duplicate code takes up too much valuable screen space.
Option 3 has a runtime cost. It has double the amount of conditionals per error point. It also adds one level of indentation per error point.
Option 4 is same as option 2 but you edit all error paths in one single place. However, this comes at the cost of having to write 2 functions instead of 1 for every function that can error. And you can still mess up and return while forgetting to call the cleanup function.
You must also consider that erroring functions are contagious, just like async ones. I'd say most of the time a function is propagated upwards, with very few being handled just as it ocurrs. This means that whichever downside your option has, you'll have to deal with it in the whole call stack.
On Error Resume Next