A neat (?) error handling system

Discussion in 'C Programming' started by Robert Latest, Apr 20, 2006.

  1. Hello folks,

    I'm finding myself in a situation where I write plenty of code where
    "stacks" of function calls appear quite frequently, as shown below. Of
    course it would be tedious to check the return value of each and every
    function call, and I never really warmed to setjmp() and longjmp().

    So I modified my error-prone functions to accept an additional
    parameter. Before doing anything else, each function performs this
    little bit of code:

    void foo (int *err)
    {
    if (err && *err) {
    ++*err;
    } else {
    /* do stuff */
    /* set *err = 1 when something fails */
    }
    }

    So if an error has already occured elsewhere, the function increments
    the value err points to and immediately returns. If an error occurs
    inside the function, *err is set to 1 and the function exits. This not
    only implements a convenient "fall-through" mechanism, but it also
    permits localization of the function call that failed, as shown in the
    example code below. I admit the errline idea is definetely taking the
    concept too far because it breaks if anything but an err-aware function
    call is inserted in between, but you get the drift.

    Sample code:

    --------------------------

    int foo(blah)
    {
    int err = 0;
    int errline;
    struct command *cmd;

    cmd = cmd_new(&err);
    cmd_append16(cmd, CMD_START, &err); /* in my code, I have */
    cmd_append32(cmd, p->feedback, &err); /* chunks like this that */
    cmd_append32(cmd, p->offset_x, &err); /* span a dozen lines or */
    cmd_append8(cmd, p->port, &err); /* more */
    cmd_write(link, cmd, &err);
    errline = __LINE__-err;
    cmd_free(cmd);
    if (err) {
    fprintf(stderr, "Function call on line %d failed\n", errline);
    }
    return err ? -1 : 0;
    }

    -------------------------

    What's the point of this posting? If you think this is a cool idea, feel
    free to use it in your code. If you think it stinks, tell me why.

    Thanks,
    robert
    Robert Latest, Apr 20, 2006
    #1
    1. Advertising

  2. Robert Latest wrote:
    > Hello folks,
    >
    > I'm finding myself in a situation where I write plenty of code where
    > "stacks" of function calls appear quite frequently, as shown below. Of
    > course it would be tedious to check the return value of each and every
    > function call, and I never really warmed to setjmp() and longjmp().
    >
    > So I modified my error-prone functions to accept an additional
    > parameter. Before doing anything else, each function performs this
    > little bit of code:
    >
    > void foo (int *err)
    > {
    > if (err && *err) {
    > ++*err;
    > } else {
    > /* do stuff */
    > /* set *err = 1 when something fails */
    > }
    > }


    Err, if `err` is NULL, you fall through to the `else` block. If you
    then encounter an error an try to set `*err` to 1. BANG!

    I'd test for NULL separately, and probably abort if it happened, as
    it's more likely than not to be a sign of a serious bug. Alternatively,
    you could say that `err` being NULL disables the whole mechanism. The
    latter is likely to be harder to maintain.
    Vladimir S. Oka, Apr 20, 2006
    #2
    1. Advertising

  3. On Thu, 20 Apr 2006 04:00:46 -0700, Vladimir S. Oka wrote:

    >
    > Robert Latest wrote:
    >> Hello folks,
    >>
    >> I'm finding myself in a situation where I write plenty of code where
    >> "stacks" of function calls appear quite frequently, as shown below. Of
    >> course it would be tedious to check the return value of each and every
    >> function call, and I never really warmed to setjmp() and longjmp().
    >>
    >> So I modified my error-prone functions to accept an additional
    >> parameter. Before doing anything else, each function performs this
    >> little bit of code:
    >>
    >> void foo (int *err)
    >> {
    >> if (err && *err) {
    >> ++*err;
    >> } else {
    >> /* do stuff */
    >> /* set *err = 1 when something fails */
    >> }
    >> }

    >
    > Err, if `err` is NULL, you fall through to the `else` block. If you
    > then encounter an error an try to set `*err` to 1. BANG!
    >
    > I'd test for NULL separately, and probably abort if it happened, as
    > it's more likely than not to be a sign of a serious bug. Alternatively,
    > you could say that `err` being NULL disables the whole mechanism. The
    > latter is likely to be harder to maintain.



    Also, shouldn't it be "++(*err);" ?. Further, its not inconceivable that
    err gets incremented so many times that it get backs to 0. Trouble!
    Duncan Muirhead, Apr 20, 2006
    #3
  4. On 20 Apr 2006 04:00:46 -0700,
    Vladimir S. Oka <> wrote
    in Msg. <>

    > Err, if `err` is NULL, you fall through to the `else` block. If you
    > then encounter an error an try to set `*err` to 1. BANG!


    In the actual code, I of course test for that:

    if (something_wrong) {
    if (err) *err = 1;
    ....
    }

    robert
    Robert Latest, Apr 20, 2006
    #4
  5. On Thu, 20 Apr 2006 12:20:31 +0100,
    Duncan Muirhead <> wrote
    in Msg. <>

    > its not inconceivable that
    > err gets incremented so many times that it get backs to 0. Trouble!


    It is not, and it has been conceived. Note to self: Check and reset err
    every MAX_INT function calls.

    robert
    Robert Latest, Apr 20, 2006
    #5
  6. Robert Latest wrote:
    > On 20 Apr 2006 04:00:46 -0700,
    > Vladimir S. Oka <> wrote
    > in Msg. <>
    >
    > > Err, if `err` is NULL, you fall through to the `else` block. If you
    > > then encounter an error an try to set `*err` to 1. BANG!

    >
    > In the actual code, I of course test for that:
    >
    > if (something_wrong) {
    > if (err) *err = 1;
    > ....
    > }


    What was the point of inviting opinions if you did not show the actual
    code?
    Vladimir S. Oka, Apr 20, 2006
    #6
  7. Robert Latest

    Flash Gordon Guest

    Duncan Muirhead wrote:

    <snip>

    >>> void foo (int *err)
    >>> {
    >>> if (err && *err) {
    >>> ++*err;


    <snip>

    > Also, shouldn't it be "++(*err);" ?.


    Why? There is no possible ambiguity in ++*err and as far as I can see it
    does the same as ++(*err)

    > Further, its not inconceivable that
    > err gets incremented so many times that it get backs to 0. Trouble!


    Depends on the code. Personally I would think that if you continue
    processing for another 32767 function calls after hitting a problem you
    are nor checking often enough.
    --
    Flash Gordon, living in interesting times.
    Web site - http://home.flash-gordon.me.uk/
    comp.lang.c posting guidelines and intro:
    http://clc-wiki.net/wiki/Intro_to_clc
    Flash Gordon, Apr 20, 2006
    #7
  8. On Thu, 20 Apr 2006 14:49:04 +0100, Flash Gordon wrote:

    > Duncan Muirhead wrote:
    >
    > <snip>
    >
    >>>> void foo (int *err)
    >>>> {
    >>>> if (err && *err) {
    >>>> ++*err;

    >
    > <snip>
    >
    >> Also, shouldn't it be "++(*err);" ?.

    >
    > Why? There is no possible ambiguity in ++*err and as far as I can see it
    > does the same as ++(*err)
    >

    You're right, but of course *p++ and (*p)++ are quite different, and
    so I prefer to use superfluous brackets in ++(*err), to guard against
    thoughtless changes.. But I shouldn't have made that point.

    > > Further, its not inconceivable that
    >> err gets incremented so many times that it get backs to 0. Trouble!

    >
    > Depends on the code. Personally I would think that if you continue
    > processing for another 32767 function calls after hitting a problem you
    > are nor checking often enough.
    Duncan Muirhead, Apr 20, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew FPGA
    Replies:
    14
    Views:
    876
    Mike Treseler
    Apr 5, 2006
  2. Ashraf Fouad

    Neat, simple, confirmed solution

    Ashraf Fouad, Dec 29, 2003, in forum: Java
    Replies:
    0
    Views:
    349
    Ashraf Fouad
    Dec 29, 2003
  3. Andrew FPGA
    Replies:
    8
    Views:
    3,852
  4. Spin

    How's this for neat code?

    Spin, Nov 27, 2003, in forum: HTML
    Replies:
    6
    Views:
    561
  5. Paj
    Replies:
    1
    Views:
    269
    gene tani
    Jul 23, 2005
Loading...

Share This Page