This is an interesting post, but I have a few points. First, there are certain kinds of error conditions where it's better to crash (producing a core dump) and

This is an interesting post, but I have a few points. First, there are certain kinds of error conditions where it's better to crash (producing a core dump) and restart rather than "swallow" the condition (even if it's logged). Java attempted to differentiate in this realm by introducing checked exceptions (where you could explicitly say this is an error condition where you can and should recover from, this is an error condition that you might not be able to recover from), but it hasn't had the intended effect (exceptions are simply seen as boiler plate and are wrapped in a try { } catch (Exception e) { logger.error(e); } block; checked exceptions are seen as a mistake). Null pointers are typically be exactly such errors: e.g., you failed to allocate memory and malloc returned NULL, you didn't do proper validation on input or you assumed a key exists in a hash table when it doesn't. Either assumption that pointer is not NULL is an invariant (in which case it's better to crash and leave a core dump), or it's not (in which case the application should do a check for a null pointer). It's also not advised to do complex processing inside signal handlers: the idea is to perform a single atomic operation in a signal handler (e.g., change an integer from 0 to 1), and let the application examine that operation's side effects. For example, there could be a "should_quit" integer which when 1 would mean the event loop should terminate and the signal handler would just set that integer to 1.