One thing that hasn't been pointed out is how the Common Lisp condition system provides a sane alternative to the Unix signal(7) brain-damage. To quote the Hyperspec:
If the condition is not handled, signal returns nil.
I think they really serve different purposes. signal(7) is a software interrupt mechanism. Its purpose is to allow your program to respond to external events without having to poll for them. (In particular, it provides a way for your program to exit gracefully when it's stuck in an infinite loop and the user kills it, and it provides a way for your program to handle page faults in userland — too bad the parameters needed to handle page faults aren't standardized across Unices.)
Like other interrupt mechanisms, it also gets used for error exits in languages that don't have them inherently, but it's a pretty bad way to do that.
If you take a look at Kent Pitman's paper, linked from the post, (http://www.nhplace.com/kent/Papers/Condition-Handling-2001.h...), particularly the section 'Unifying "Signals" and "Exceptions"', he points out that signal(7) is actually doing two orthogonal things - process interrupt, and signal raising.
He also points out how the signal(7) and Lisp conditions came out of Multics. If you consider it that way, it becomes clear that the Unix decision to overload signal(7) with two different functions is why it is such a poor interface and major source of pain.
Like other interrupt mechanisms, it also gets used for error exits in languages that don't have them inherently, but it's a pretty bad way to do that.