arithma wroteBut how do you know what memory to deallocate in wherever you go to? In this case, goto is worse than both "nesting branches solely because of error handlng" and using "exception throwing/catching" mechanisms.
I think
this answer shows how I see it.
Notice how the
error labels are still in the same scope as the
goto call, and worse case scenario, you can always pass something as a param to the cleanup function. The goal is to make it behave as much as possible like "nesting branches because of error handling", yet keeping the code clean enough so that error handling does not clutter the view away from the true purpose of your algorithm.
By the way, what I meant by what quote me saying was: Should we always return a tuple of (success_state, return_value) for functions that may return an error.
It is exactly because of this, that lately I'm trying to steer away from return_values and favor something like this:
int function(void *somevalue)
{
// modify the value of the variable pointed at by somevalue
return success_state;
}
Is it possible to consider that return values of functions in C should only be used for error checking? That's what I'm trying to find out.
One thing is sure though, this is an incredibly imperative mindset, and does not play well with concurrency.
Honestly, I don't have the answers. Error handling is one of the toughest problems I face in my code...