Artefact:Model/com/sphenon/basics/exception/ExceptionError

Code
> java.lang.Error
 * ExceptionError

Description
ExceptionErrors reflect "real" (i.e. in fact exceptional) exceptions, i.e. erraneous, unforeseeable and typically not handable situations. The name emphasises this excepional, erraneous character.

The decision to derive from  instead of  was made with intent. The contract of  states explicitly "that a reasonable application might want to catch" them. This is simply not true for the kind of exceptions defined here, since they reflect actual errors. No reasonable application should catch them, except for robust server main loops, but these may want to catch every  anyway.

These exceptions do not belong to the contract, since declaring them in the interface of the class would be the same as saying "This class can be faulty due to bugs or misconfiguration", which is of at least questionable usefullness.

In contrast to the semi-consequent solution of the introduction of s, we make a sharp and easily understandable distinction here between actual errors and normal processing conditions. An index out of bounds can have several different causes: a faulty vm, a programming error, a usage error by another programmer (contract violation), an end user input error. The cases should be distinguished and each one handled appropriately. Just allowing to throw the respective exception in any circumstance is misguided.

Classes dervied from ExceptionError provide a categorisation which shall help locating the effective cause of the problem as far as possible. Additional information, supporting this goal, should be provided within the message and context.

In contrast to ExceptionErrors, ReturnCodes reflect normal process results which should be handled by the caller.

In case you are concerned with transaction failure handling, please be sure to also read and understand the documentation of TransactionFailures and the various implications.