Difference between revisions of "Artefact:Model/com/sphenon/basics/exception/ExceptionError"

From OOModels
< Artefact:Model‎ | com‎ | sphenon‎ | basics‎ | exception
Jump to navigationJump to search
 
(5 intermediate revisions by the same user not shown)
Line 4: Line 4:
| Meta_Category              = Type:org/oomodels/wiki/Model
| Meta_Category              = Type:org/oomodels/wiki/Model
| Meta_Download              = true
| Meta_Download              = true
| Meta_Diagram                = Artefact:Diagram/com/sphenon/basics/exception/Exceptions
| Meta_AddTypeToCategory    = true
| Meta_AddTypeToCategory    = true
| Meta_AddCategoryToCategory = true
| Meta_AddCategoryToCategory = true
Line 11: Line 12:


<wiml>
<wiml>
* ExceptionError Exception
* ExceptionError
   > java.lang.Error
   > java.lang.Error
</wiml>
</wiml>
== 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 <code>Error</code> instead of
<code>RuntimeException</code> was made with intent. The
contract of <code>Exception</code> 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 <code>Throwable</code> 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
<code>RuntimeException</code>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 [[Artefact:Model/com/sphenon/basics/exception/ExceptionError|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 [[Artefact:Model/com/sphenon/basics/exception/ExceptionError|ExceptionError]]s,
[[Artefact:Model/com/sphenon/basics/exception/ReturnCode|ReturnCode]]s
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 [[Artefact:Model/com/sphenon/basics/exception/TransactionFailure|TransactionFailure]]s
and the various implications.

Latest revision as of 10:00, 26 March 2010

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


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, 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.