Difference between revisions of "Artefact:Model/com/sphenon/basics/exception/ExceptionError"
AndreasLeue (talk | contribs) |
AndreasLeue (talk | contribs) |
||
| (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 | * 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]
| ||||||
| 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.
