Error handling style in C

Re:Error handling style in C by exDM69 on Tuesday April 24, 2012 @08:03AM (#3883529)

A forward jumping goto (to a single target inside a function) is just perfect for C error handling code. Don't be misguided by a silly principle of goto's being always bad. They get the job done in the cleanest possible way, so you should use them for doing cleanups.

The examples did not have any resources to clean up, and that is what makes error handling in C painful. In the absence of any cleanup routines, this will do:

  return (
    do_something() == SUCCESS &&
    do_something_else() == SUCCESS &&
    do_final_thing() == SUCCESS) ? SUCCESS : FAILURE;

Of course, once you add resources to clean up or error codes that are meaningful (not just success/fail) error handling gets more painful.

You should not try to perfect something as mundane as error handling. Just write the damn code and get over it.

[ Parent | on HN ]

Re:Error handling style in C by tspiteri on Tuesday April 24, 2012 @08:28AM (#3883606)

Why should the goto be to one single target? Multiple goto statements are good for multiple clean ups without adding indentation levels and without having artificially long logic ands. For example:

    int init_abc()
    {
        if (!init_a())
            goto err_a;
        if (!init_b())
            goto err_b;
        if (!init_c())
            goto err_c;
        return 1;

     err_c:
        cleanup_b();
     err_b:
        cleanup_a();
     err_a:
        return 0;
    }

seems to be the cleanest way to do what it does in C. For what it's worth, it is the way a lot of error handling is done in the Linux kernel.

[ Parent | on HN ]

Re:Error handling style in C by exDM69 on Tuesday April 24, 2012 @08:35AM (#3883624)

I guess it's fine to use multiple targets too. However, usually you can get away with one, because free(NULL) and similar cleanups tend to be no-ops. So you have something like:

    char *foo = 0, *bar = 0;
    if((foo = malloc(X)) == NULL || (bar = malloc(Y)) == NULL)
      goto cleanup;
    make_me_millions(foo, bar);

  cleanup:
    free(bar);
    free(foo);

In this case, and many cases like it, there's no need to have two jump targets, because one is good enough. You'll have to declare the variables early on anyway to avoid warnings/errors from definitions that cross jump labels.

So there's probably nothing wrong with multiple jump targets but that might not be needed with well-behaving cleanup functions.

[ Parent | on HN ]

Re:Error handling style in C by adestefan on Tuesday April 24, 2012 @09:30AM (#3883816)

because free(NULL) and similar cleanups tend to be no-ops. So you have something like

You really need to check the specification on each function. free is defined that free(NULL) is no-op, but there are other things where that is not the case. Also, that code is not portable since NULL does not have to be 0.

[ Parent | on HN ]

Re:Error handling style in C by cdellin on Tuesday April 24, 2012 @09:52AM (#3883900)

Just a correction: the code is actually perfectly portable. The integer constant 0 is the canonical definition of the null pointer by definition in the standard (See Section 6.2.2.3 "Pointers" in C89). The null pointer constant (NULL) is defined primarily for convenience (so a reader knows you mean a null pointer instead of a arithmetic zero). Of course, the bitwise representation of the null pointer need not be all-bits-zero; that is, NULL = (void )0 != ((int *)&0).

[ Parent | on HN ]

Re:Error handling style in C by adestefan on Tuesday April 24, 2012 @10:06AM (#3883974)

I stand corrected, it does define the integer constant 0 to be promoted to the null pointer. In C11 this is Section 6.3.2.3. To make it even more confusing Section 7.19 Common Definitions <stddef.h> defines NULL to be an implementation depefined null pointer constant.

I was always taught that (void *)0 is a valid definition of NULL, but that 0 was not necessarily.

[ Parent | on HN ]

Re:Error handling style in C by exDM69 on Tuesday April 24, 2012 @10:55AM (#3884193)

> You really need to check the specification on each function.

Sure, but I need to do that anyway and constantly, since I use far too many API's to memorize. It's also convenient to make cleanup(NULL) a no-op for the API's you create.

NULL is zero. Even if the standard would allow it to be something else, it's not relevant with the compilers and platforms I use. There's no point in being a language lawyer just to achieve "portability" to some imaginary platform where a byte is 7 bits and NULL == 0xdeadbeef. Make a list of compilers and platforms you support and forget the rest if you want to get stuff done.

[ Parent | on HN ]

Re:Error handling style in C by cube13 on Tuesday April 24, 2012 @01:43PM (#3885272)

I'm actually curious how the compilers would handle this. The compiler may inline the gotos so it's really:

  int init_abc()
  {
      if(!init_a())
          return 0;
      if(!init_b())
          cleanup_a();
          return 0;
      if(!init_c())
          cleanup_a();
          cleanup_b();
          return 0;
      return 1;
  }

[ Parent | on HN ]

Re:Error handling style in C by mtoddh on Tuesday April 24, 2012 @08:36AM (#3883631)

Good points - it also a lot easier to debug what's being returned by the function as you have fewer breakpoints to set in gdb.

[ Parent | on HN ]