Proper error detection and recovery is often ignored by UNIX developers. The lack of exceptions from the C language and the rudimentary error mechanisms from the standard C library certainly contribute to this. This article familiarizes you with the UNIX standard error reporting mechanism, the errno global variable. You’ll also learn about a couple of associated global variables ( sys_nerr and sys_errlist) and the standard functions that help you report errors to the user and (hopefully) encourages you to report and handle errors in a user-friendly way.
UNIX Error Reporting in the Standard C Library
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
about stderr…
Too bad that an introduction to error reporting in unix left out
a) fprintf(stderr,…)
and
b) the return value from main …
We did *not* leave out E_OK or its equivalent in P1003 by accident. There’s a _reason_ why 0 is the OK return value, and it has to do with a common C idiom that should be in every C programmer’s vocabulary:
fd = open(…);
if (!fd) {
/* YOU FAILED */
}
which is more commonly used for functions that return a status and so don’t need the assignment:
if (!somefunction()) {
/* YOU FAILED */
}
Why on earth did you use open for this example? It like most such functions returns -1 on error making it a fairly poor choice for discussing a lazy shorthand that doesn’t even apply with its use.
The reason EOK was probably never introduced into POSIX is that errno is not defined to detect errors, but rather to report specific errors. The value of errno should only be used when a function specifically defined as setting errno in the event of some error condition signals that an error has occurred. This is typically done by that function returning -1.
doh! I used open because the example did and I didn’t pay attention. My bad.
Now that I’m awake: ignore my original post in this thread. it was a brane fart.
Thanks for the correction.
And while I’m at it, main returns EXIT_SUCCESS on success because it’s defined by the C standard. This happens to be 0, but that is not strictly necessary.
Semantically, checking for EXIT_SUCCESS after function calls would look a bit weird to someone reading the program (sure, the function is exitting, but still)…
– chrish
Proper error detection and recovery is often ignored by UNIX developers.
WHAT?!!!
errno is there a long time ago, but for what we have today in a lot of languages with exceptions seems a good deal more powerful.
… Yeah, sure, exception is much more powerful.
If you need fine grained error recovery, instead of doing:
int err;
..
if ((err = command(…)) < 0) {
/* Fine grained error recovery. */
err = errno;
goto out;
}
You do:
int previous_err = 0;
int err = 0;
…
if (!previous_err) {
try {
command(…);
}
catch (…) {
// Fine gained error recovery.
…
// No goto. We don’t do such things in
// CPP. Lets us just do if previous_err
// 128 times till the end of the function.
previous_err = err;
}
}
<SARCASM>
Yep, indeed C++ exception is much better at fine-grained error recovery then C
is.
Thank God kernels and OS libraries are still written in C!
</SARCASM>
– Gilboa
* Sorry about that… I’m just faced, on a daily basis, by herd of C++ programmers who throw C++ on each stupid error, failing to do any type of error recovery and leaving all the clean up to the CPP/C libraries/drivers/etc.
Edited 2006-09-08 21:47
Ugh, sorry, that doesn’t seem good C++ style to me. I don’t just catch errors and then later figure the errors out again by a lot of if-statements.
This article should be marked as introductory. There is no point on talking about errors at intermediate level on Unix without explaining the mechanisms behind signal, setjmp and longjmp as many errors will not be caught.
I agree, but I don’t get to assign the level.
– chrish
Awww… c’mon! What could be more user-friendly than reporting that a user’s printer is “on fire”[1]?
(unless, of course, it is just offline)
[1] http://www.kalamazoolinux.org/mailarchive/0006/msg00188.html