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

From OOModels
< Artefact:Model‎ | com‎ | sphenon‎ | basics‎ | exception
Revision as of 09:04, 26 March 2010 by AndreasLeue (talk | contribs)
Jump to navigationJump to search
Classification
Type Type:org/oomodels/WIML/1.0
Domain Domain:it/test
Category Type:org/oomodels/wiki/Model
More
Download Code
Diagram
Namespace (more)
create new pages

Code[edit]

java.lang.Error
ExceptionError
«Exception»


Description[edit]

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 Error instead of RuntimeException was made with intent. The contract of Exception 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 Throwable 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 RuntimeExceptions, 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, ReturnCodegs 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.