Error handling style in C

21,091 13
Summary

Exploring common C error handling patterns, three distinct styles are presented, each with identified drawbacks. One approach uses a boolean flag to sequentially gate operations, which can be insufficient and error-prone for complex flows. Another employs goto statements for early exit on failure, a method often criticized for its impact on code readability and structure. Finally, deeply nested if conditions are shown, leading to complex and hard-to-read "arrow code." Developers are invited to evaluate these patterns and consider their own preferred robust error management strategies in C.

Following are three error handling styles in C.Which one you like the most? Or you don't like any one?

1. /* Problem : Not enough. Easy to be wrong */
int foo(int bar)
{
        int return_value = 0;
        int doing_okay = 1;
        doing_okay = do_something( bar );
        if (doing_okay)
        {
                doing_okay = init_stuff();
        }
        if (doing_okay)
        {
                doing_okay = prepare_stuff();
        }
        if (doing_okay)
        {
                return_value = do_the_thing( bar );
        }
        return return_value;
}


2. /* Problem : Use goto is a bad idea */
int foo(int bar)
{
        if (!do_something( bar )) {
                goto error;
        }
        if (!init_stuff( bar )) {
                goto error;
        }
        if (!prepare_stuff( bar )) {
                goto error;
        }
        return do_the_thing( bar );
error:
        return 0;
}

3. /* Problem : Too many nested if statement. Hard to read */
int foo(int bar)
{
        int return_value = 0;
        if (do_something( bar )) {
                if (init_stuff( bar )) {
                        if (prepare_stuff( bar )) {
                                return_value = do_the_thing( bar );
                         }
                }
        }
        return return_value;
}

Author : Source : http://coolshell.cn/articles/551.html
C ERROR HANDLING STYLE GOTO NESTED IF

  RELATED

  COMMENTS

13
Mark
Apr 24, 2012 at 8:03 am
Reply
CException.sourceforge.net :)
Menny
Apr 24, 2012 at 8:05 am
Reply
Or this: int return_value = 0; if (do_something( bar ) && init_stuff( bar ) && prepare_stuff( bar )) { return_value = do_the_thing( bar ); } return return_value;
m0skit0
Apr 24, 2012 at 8:09 am
Reply
@Menny: yeah, that's way more readable :P
Carl
Apr 24, 2012 at 8:30 am
Reply
I'm so sick of this "got is bad!" bullsh*t and FUD in C programming. There is nothing wrong with using goto. It's like saying scissors are bad because if you run around with them, you might trip and hurt yourself. Learn how to use the tool correctly instead of saying that it's "bad". Grep the Linux kernel source code for instances of goto and you will come up with over 500 occurances. Bad using goto? No. Just use it the proper way and it's fine.
Dengo
Apr 24, 2012 at 8:30 am
Reply
Why is using goto a bad idea?
kyle
Apr 24, 2012 at 8:38 am
Reply
I would do something like if ((do_something(bar) >= 0) && (init_stuff(bar) >= 0) && (prepare_stuff(bar) >= 0)) return_value = do_the_thing(bar); else warn("context"); return return_value;
luciofm
Apr 24, 2012 at 9:20 am
Reply
Stop reading on "Use goto is a bad idea" People continue to throw this as an undeniable truth.
clavijo
Apr 24, 2012 at 10:49 am
Reply
int ok = 1; ok = ok && foo(); ok = ok && bar(); ok = ok && baz(); return ok;
kyledrake
Apr 24, 2012 at 10:52 am
Reply
Goto was designed for stuff like this. See the K&R C book.
chenbo
Apr 24, 2012 at 11:26 am
Reply
I would say that all the three styles are OK if it's used in a clean & consistent way. Your example codes are all easy to read. I do not understand how could #1 to be easy to be wrong. For #2, using GOTO is all right. So as #3.
aguynamedryan
Apr 24, 2012 at 11:42 am
Reply
What about returning early out of the function? Avoids the nesting problem of #3 and the goto in #2: int foo(int bar) { int return_value = 0; if (!do_something( bar )) { return return_value; } if (!init_stuff( bar )) { return return_value; } if (!prepare_stuff( bar )) { return return_value; } return do_the_thing( bar ); }
webreac
Apr 24, 2012 at 12:40 pm
Reply
Your first solution is not elegant in your case, but in some cases, the principle may be acceptable. There is nothing wrong with goto (except for bad teachers). It allows to have a structure very similar to exception handling which may be desirable in some cases. Each time, I find constructions that are more elegant with a goto, I try to use goto. It occurred 3 times in 20 years. Only one of them reached production: the two others ones disappeared when defects of the specifications were removed. Goto should not be avoided, but it is rarely the best solution. The third solution is the one we try to avoid. The most common solutions to avoid nested if are "short-circuiting boolean operators (&& ||)" or "usage of subroutines". Sometimes mixed with your first solution.
doodables
Apr 24, 2012 at 1:54 pm
Reply
I used to work with a bunch of people who thought a do { } while(false); loop was a great solution to this problem, because you get to use goto functionality without using goto! Ridiculous. Go back and read the "goto considered harmful" essay and try to understand it and realize that it's complaining *misuses* of goto, not proper uses, which do exist.