Exceptions revisited

Exceptions are another of those constructs that puts the power with the designer/implemeter instead of the user. The designer decides to throw the exception - now the user HAS to handle it by hook or crook.

To reverse the power the current exceptions style mechanism has to be remove. As stated earlier Dawn does not have return value, values are propagated forward through calls. Thus is it easy to signal errors by calling forward through an output. The user can ignore it, which puts the responsibility on the implementer to make sure that the component lives with faults without terminating or crashing.

The user can decide to pipe this error output into a logger, or reinstate the exception mechanism by terminating the scope (for which I have to find a graceful mechanism, break is not my favorite keyword).

This will lead to fault oblivious software, where faults in functionality will be faults in functionality only - not the mess today where faults in functionality can lead to application crashes, which makes a fault more serious than necessary.

This is also why null is NOT a big mistake - its just the handling thats the mistake i.e. the crash. Just be oblivious to it, and grace is reinstated.

What? Faulty software? Ah, you still live in the world where you think software can be without faults..