lib: Composable Error Handling

[fridis]

PR #3157 is a step in this direction for pre- and postconditions, but we should aim to have a general solution. I found a nice blog post explaining the general problem by Vladimir Keleshev. Our solution should permit composition as described in the blog post, while I would not go for a result type that is a choice of the actual result and a generic error type, but for a plain result type and some abortable effect in the error case.

Then, I would like to go one step further and permit a hierarchy of errors, such that one can decide to handle specific errors locally, but pass other errors on to the caller. This is similar to Java's Throwable which builds a tree of exceptions classes. I would rather have an effect for each particular error, and then implement implement this error using a more generic error. E.g., there might be the hierarchy

• arithmetic overflow
• numeric error
• contract fault
• general fault

Such that code could be specific and, e.g., decide to handle a numeric error locally and, e.g., retry a calculation with a larger numeric type, while more general faults are handled outside. Java distringuishes

• Error, which is typically exhaustion of a resource like memory, but often used for software bugs
• RuntimeException, typically a software bug, and
• Exception, typically an expected condition like invalid input or network connection failure

we should have similar categories with the possibility of adding more categories.

A simple outcome which is a choice between a result value and an error should IMHO still exist for operations that typically require immediate error handling. Plus a mechanism to easily convert between outcomes and exception effects.