By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,745 Members | 1,873 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,745 IT Pros & Developers. It's quick & easy.

A neat (?) error handling system

P: n/a
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
Apr 20 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a

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.

Apr 20 '06 #2

P: n/a
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!
Apr 20 '06 #3

P: n/a
On 20 Apr 2006 04:00:46 -0700,
Vladimir S. Oka <no****@btopenworld.com> wrote
in Msg. <11*********************@u72g2000cwu.googlegroups. com>
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
Apr 20 '06 #4

P: n/a
On Thu, 20 Apr 2006 12:20:31 +0100,
Duncan Muirhead <no***@this.address> wrote
in Msg. <pa****************************@this.address>
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
Apr 20 '06 #5

P: n/a

Robert Latest wrote:
On 20 Apr 2006 04:00:46 -0700,
Vladimir S. Oka <no****@btopenworld.com> wrote
in Msg. <11*********************@u72g2000cwu.googlegroups. com>
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?

Apr 20 '06 #6

P: n/a
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
Apr 20 '06 #7

P: n/a
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.


Apr 20 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.