Linked by Eugenia Loli on Fri 8th Sep 2006 04:08 UTC
General Development 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.
Order by: Score:
pity
by Cloudy on Fri 8th Sep 2006 04:20 UTC
Cloudy
Member since:
2006-02-15

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 */
}

Reply Score: 4

RE: pity
by Get a Life on Fri 8th Sep 2006 16:57 UTC in reply to "pity"
Get a Life Member since:
2006-01-01

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.

Reply Score: 1

RE[2]: pity
by Cloudy on Fri 8th Sep 2006 18:23 UTC in reply to "RE: pity"
Cloudy Member since:
2006-02-15

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.

Reply Score: 1

RE: pity
by Get a Life on Fri 8th Sep 2006 17:14 UTC in reply to "pity"
Get a Life Member since:
2006-01-01

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.

Reply Score: 1

RE[2]: pity
by chrish on Sat 9th Sep 2006 15:53 UTC in reply to "RE: pity"
chrish Member since:
2005-07-14

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

Reply Score: 1

Too big a statement...
by AkiFoblesia on Fri 8th Sep 2006 04:43 UTC
AkiFoblesia
Member since:
2006-07-25

Proper error detection and recovery is often ignored by UNIX developers.

WHAT?!!!

Reply Score: 3

Well, ...
by Legend on Fri 8th Sep 2006 07:29 UTC
Legend
Member since:
2006-07-27

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.

Reply Score: 1

RE: Well, ...
by gilboa on Fri 8th Sep 2006 21:46 UTC in reply to "Well, ..."
gilboa Member since:
2005-07-06

... 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

Reply Score: 1

RE[2]: Well, ...
by Legend on Sat 9th Sep 2006 10:59 UTC in reply to "RE: Well, ..."
Legend Member since:
2006-07-27

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.

Reply Score: 1

signal, setjmp, longjmp
by acobar on Fri 8th Sep 2006 09:02 UTC
acobar
Member since:
2005-11-15

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.

Reply Score: 1

RE: signal, setjmp, longjmp
by chrish on Fri 8th Sep 2006 13:08 UTC in reply to "signal, setjmp, longjmp"
chrish Member since:
2005-07-14

I agree, but I don't get to assign the level.

- chrish

Reply Score: 1

(not so) Seriously, folks...
by markjensen on Fri 8th Sep 2006 13:15 UTC
markjensen
Member since:
2005-07-26

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

Reply Score: 1