Error handling

[Alberto Giménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there! I'm doing some homework (almost finished), but now i'm
reconsidering a design decission I made at the beginning. This is about
error handling in functions. I have my functions returning 0 if OK, and
an "enum" error indicating the type of error. A typical pseudo-code is
like:

if (error1)
return E_NOMEM;

....

if (error2)
return E_CLOSED;

....

Then, I have some modules calling functions of some others, so I have up
to 3-deep "own function calling". Each of this "deep level" returns 2 or
3 kinds of error (E_FOO, E_BAR,...), and I considered to bypass all
error to topmost calling function or even main program, but the
problem is that in the main program i should have a code like:

status = myfunc ();
switch (status) {
case 0: /* ok */
...
case E_NOMEM:
...
case E_CLOSED:
...
}

and something like this for all my functions returning more than one
value indicating a diferent error. This way my program can indicate
more or less exactly what produced an error in the execution.

I've seen that standard C functions use -1 for error, modifying errno,
but I don't like this handling, because i would have personal error
types. In the other hand, my error handling and bypassing is not very
good (I think).

Now I'm considering to just return -1 (or another nonzero value) in all
functions if there is any error, and the top caller just would indicate
something like "there was an error in myfunc ()" (with no clue if there
was a sub-call error inside myfunc).

I'm doing error-bypassing to the caller because I want my code
modular, and don't want IO functions messing around inside my
modules (a kind of OOP). For this reason, only the main program should
write messages to the user.

In the other hand, does C standard say anything about error handling in
functions?

TIA

- --
Alberto Giménez, SimManiac en el IRC
http://www.almorranasozial.es.vg
GNU/Linux Debian Woody 3.0 GnuPG ID: 0x3BAABDE1
Linux registered user #290801
Iniciando Windows 98... 2 horas despues.... Iniciando Windows 98...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAh+WR0keCtzuqveERAlP+AJ9IN+qpwkTJ0TQ3rv2BlQ wEB3DESgCeIzjD
SrcKrjKmKCcAjij0SkECogc=
=PIEb
-----END PGP SIGNATURE-----

[Barry Schwarz]

On Thu, 22 Apr 2004 17:32:33 +0200, Alberto Giménez
<al****@teleline.es> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there! I'm doing some homework (almost finished), but now i'm
reconsidering a design decission I made at the beginning. This is about
error handling in functions. I have my functions returning 0 if OK, and
an "enum" error indicating the type of error. A typical pseudo-code is
like:

if (error1)
return E_NOMEM;

...

if (error2)
return E_CLOSED;

...

Then, I have some modules calling functions of some others, so I have up
to 3-deep "own function calling". Each of this "deep level" returns 2 or
3 kinds of error (E_FOO, E_BAR,...), and I considered to bypass all
error to topmost calling function or even main program, but the
problem is that in the main program i should have a code like:

status = myfunc ();
switch (status) {
case 0: /* ok */
...
case E_NOMEM:
...
case E_CLOSED:
...
}

and something like this for all my functions returning more than one
value indicating a diferent error. This way my program can indicate
more or less exactly what produced an error in the execution.

I've seen that standard C functions use -1 for error, modifying errno,
Which ones do you think use -1 to indicate errors. I know some that
use NULL, some that use EOF, at least one that uses 1, and a few that
use 0, and at least one where -1 is a normal return value. But off
the top of my head I cannot think of one that uses -1.
but I don't like this handling, because i would have personal error
types. In the other hand, my error handling and bypassing is not very
good (I think).

Now I'm considering to just return -1 (or another nonzero value) in all
functions if there is any error, and the top caller just would indicate
something like "there was an error in myfunc ()" (with no clue if there
was a sub-call error inside myfunc).
Instructor preferences vary but when I was teaching I always gave
preference to user friendliness. Will including a function name in an
error message be meaningful to your user?

I'm doing error-bypassing to the caller because I want my code
modular, and don't want IO functions messing around inside my
modules (a kind of OOP). For this reason, only the main program should
write messages to the user.

In the other hand, does C standard say anything about error handling in
functions?
For those functions which return an error indication, the standard
specifies what that indication is on a function by function basis.
The standard does not specify what your program should do when such a
condition is indicated.
TIA

<<Remove the del for email>>

[Alberto Giménez]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 23 Apr 2004 00:47:29 GMT, Barry Schwarz escribió:

I've seen that standard C functions use -1 for error, modifying errno,
Which ones do you think use -1 to indicate errors. I know some that
use NULL, some that use EOF, at least one that uses 1, and a few that
use 0, and at least one where -1 is a normal return value. But off
the top of my head I cannot think of one that uses -1.

Hm, well, i think i meant system dependent system calls instead of
standard C functions, but I found "mktime", and rationale says that
should return (time_t) -1 on error (can't figure out how "standard" can
be the rationale itself).

Instructor preferences vary but when I was teaching I always gave
preference to user friendliness. Will including a function name in an
error message be meaningful to your user?

I don't mean to put the function name, but including what the function
does, as an example, let's imagine a function that creates a socket for
a server to "hear" on it. Let's name that function "create_socket" that
function calls to another function called "socket", another called
"bind" and some others. If that "create_socket" fails, my 2 ways of
handling the errors are:

1) say the caller which sub-call failed, for example, return E_BIND if
bind fails, or E_SOCK if socket call fails, and the caller print a useful?
message saying something like:
"couldn't create socket" or "couldn't bind server to a port", indicating
that "create_socket" failed by the "socket" call or by the "bind" call.

2) don't mind about sub-call errors, and the caller of the
"create_socket" function should say something like:
"couldn't create a server socket", indicating a general error on
"create_socket".

Greetings.

- --
Alberto Giménez, SimManiac en el IRC
http://www.almorranasozial.es.vg
GNU/Linux Debian Woody 3.0 GnuPG ID: 0x3BAABDE1
Linux registered user #290801
Se busca ladron/estafador con buenas referencias para empresa
con gran proyeccion. Preguntar en ca********@telefonica.es .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFAiSwo0keCtzuqveERApeSAJ0bgKIG5Zvc8LaGB/pNCwgTGVAQ0gCgioZb
3Iw3/xV8gff96zAL+LzzG9A=
=Ta65
-----END PGP SIGNATURE-----

[Malcolm]

"Alberto Giménez" <al****@teleline.es> wrote in message

I don't mean to put the function name, but including what the
function does, as an example, let's imagine a function that creates a
socket for a server to "hear" on it. Let's name that function
"create_socket" that function calls to another function called
"socket", another called "bind" and some others. If that
"create_socket" fails, my 2 ways of handling the errors are:

1) say the caller which sub-call failed, for example, return E_BIND > if bind fails, or E_SOCK if socket call fails, and the caller print a useful? message saying something like:
"couldn't create socket" or "couldn't bind server to a port",
indicating that "create_socket" failed by the "socket" call or by the
"bind" call.

2) don't mind about sub-call errors, and the caller of the
"create_socket" function should say something like:
"couldn't create a server socket", indicating a general error on
"create_socket".

This really isn't a solved problem. In C++ you should throw exceptions,
which means that high-level code will always catch an error from where it
occurred. However it won't necessarily know the particular function in which
it occurred.

I think you can look at the issue this way. There are three types of error
a) When you can't get an IO resource needed
b) When input is badly formed
c) When the program runs out of memory.

If you separate out IO then you are left with error types b) and c). With a
few exceptions, such as functions that take input to be parsed by a grammar,
if you have a type b) error then that is a mistake by the calling
programmer. In a debug environment you should assert() fail. In a user
environment things are more difficult - basically something has gone wrong
and there is no good solution. You can terminate the program with a "CD
dirty" message if you like.
A type c) error is more a theoretical than a practical problem on modern
systems if you are asking for a small amount of memory. If the system won't
give you 1Kb for a buffer then you can be pretty sure that well before then
it will have generated "memory low" warnings. So it doesn't really matter
what you do, since the error-hnadling code will be executed too infrequently
to make any difference to the user.
If you are allocating a large amount of memory then of course the situation
is different - it's quite possible that the computer will be genuinely out
of memory. So you need to pass an "out of memory" flag up the control stack.
Note that the user, or even debugging programmer, doesn't really need to
know where you ran out of memory. There's nothing wrong with the function
itself, it just doesn't have resources to execute.