Hacker News Reader

Comment by parenthesis | Hacker News Reader

  if ((result = foo()) == -1) {
     fprintf(stderr, "!$*!$&^!$*!!!!\n");
     exit(1);
  }

View on HN

If exit() is too abrupt, you can always use setjmp() and longjmp() to set up a non-local jump to an error handler.

setjmp/longjmp is essentially what exception handlers do for you. I love C for its simplicity, but I'm not certain that leaving exception handling out of the language was a good idea. There are a lot of people who would agree with me there, including (I believe) a few Bell labs veterans who wrote the language in the first place.

The nice thing about exceptions beyond setjmp/lngjmp (in C++ at least) is the destructor semantics which you can use to guarantee that resources are cleaned up on error. There are better ways to handle such things, such as scoped resource allocation, but exceptions do an ok job.

You can actually use setjmp()/longjmp() to implement that kind of thing, it turns out. Here's but one example:

http://www.on-time.com/ddj0011.htm

I'm almost tempted to make an analogy with scheme's (call-with-current-continuation) here, but I think that might be pushing it.

Agreed. I rarely exit() out of an error. I was responding to the parent's want for "a big, flashy, loud, total failure".

That won't scale. I'm sure you'll have lots of fun grepping through your source files looking for "!$!$&^!$!!!!" when it appears on your stderr. The point is that with an exception system you don't have to write stupid shit like that everywhere just to crash and burn correctly.

Failing loudly is the only sensible behavior when an unexpected error occurs and there's absolutely no indication of what to do in such a case.

This is why assert exists.

tyger(~)% cat << EOF > main.c

? #include <assert.h>

? void main( void )

? {

? assert( 0 == 1 ) ;

? }

? EOF

tyger(~)% gcc main.c

main.c: In function ‘main’:

main.c:4: warning: return type of ‘main’ is not ‘int’

tyger(~)% ./a.out

Assertion failed: (0 == 1), function main, file main.c, line 5.

Abort

tyger(~)%

From what breif comments I've read on Lisp's condition system, it sounds much better. Containing and isolating the error, as soon as possible, then passing information about the error higher up like an exception might propagate, until a level high enough to know the goal of the operation and what to do in case of errors, then passing a response back down, and being able to continue in a useful manner or tidy up gracefully.

A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour".

"A great big codesplosion spraying you with a several hundred lines of stack trace and a "Your program has encountered an error an needs to close" is not "sensible behaviour"."

Yes it is, if it's a program in development where I haven't yet decided what behavior an error condition should produce.

You guys don't seem to understand I don't necessarily want to decide how to handle all errors now, not that I never want to have to think about how to handle them.

Reply on news.ycombinator.com