Error handling is indeed very hard to get right. In Rust we've been experimenting with different mechanisms:
* Much of our code uses the Result<T,E> type for local error handling, which is very similar to the way Haskell handles exceptions with the Error monad.
* For long-distance, fatal error handling, Graydon was very influenced by the "crash-only software" paper [1]. There is a `fail` statement which brings down the task permanently with no chance of recovery. (The only code that executes after a `fail` expression is evaluated is the set of destructors attached to the data the task owns.) Of course, other tasks can continue executing and might restart the crashed task.
* For long-distance, nonfatal error handling there is a new condition system like Common Lisp's -- you register a handler and that handler gets called whenever an error happens. The handler could tell the function that signaled an error to restart with a new value, to return a value of the handler's choice, or to fail the task (the default in most cases).
The hope is that this is a more robust and performant model than the traditional exceptions model, while not being particularly verbose.
It is worth remembering that the convention in early c development was to check for null values whenever doing memory allocation. In most PC programs, this convention added considerable overhead more or less for nothing since once a program runs out of memory, recovery really possible (oh, and Linux doesn't even return zero even when out of memory, it just boot programs).
Checking for null values from malloc does not create serious overhead, it creates minor overhead for your branch predictor, unless for some reason malloc frequently returns null.
A single context switch back to the kernel generates far more load than the null checks could ever hope to accomplish.
* Much of our code uses the Result<T,E> type for local error handling, which is very similar to the way Haskell handles exceptions with the Error monad.
* For long-distance, fatal error handling, Graydon was very influenced by the "crash-only software" paper [1]. There is a `fail` statement which brings down the task permanently with no chance of recovery. (The only code that executes after a `fail` expression is evaluated is the set of destructors attached to the data the task owns.) Of course, other tasks can continue executing and might restart the crashed task.
* For long-distance, nonfatal error handling there is a new condition system like Common Lisp's -- you register a handler and that handler gets called whenever an error happens. The handler could tell the function that signaled an error to restart with a new value, to return a value of the handler's choice, or to fail the task (the default in most cases).
The hope is that this is a more robust and performant model than the traditional exceptions model, while not being particularly verbose.
[1]: https://www.usenix.org/conference/hotos-ix/crash-only-softwa...