Why exceptions for error handling is so important

[via Digitalmars-d]

On Monday, 12 January 2015 at 00:51:25 UTC, Walter Bright wrote:
> Perhaps I misunderstand, but given A calls B calls C,
>
>    A => B => C
>
> and C detects an error, and A knows what to do with the error. 
> B then becomes burdened with checking for the error, invoking 
> some sort of cleanup code, and then propagating it.

There's another reason why this is not that bad (under the 
assumption that errors are _not_ only used for premature 
termination):
The meaning of an error ist in most cases only clear in 
combination with the function call. With every step in the call 
stack you lose information about the error and the handling 
becomes more difficult.

In a well-designed interface, every function specifies all the 
errors that might happen. And by this I mean a meaningful set of 
errors that is useful for the caller, not just the union of all 
errors resulting from the implementation. Simply propagating 
errors is not really an option in that case, because higher-level 
functions often also (should) have higher-level errors (the 
lower-level root-error should still be available though).

Some random example:
Some function needs some configuration from a file, but has no 
permission -> signals a permission error.
But it doesn't make sense for C to just propagate a permission 
error. Instead it should signal a configuration error and store 
the permission error as the cause of that configuration error.