Artefact:Model/com/sphenon/basics/exception/ExceptionError
| 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]
| ||||||
| 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.
