Artefact:Model/com/sphenon/basics/exception/TransactionFailure
| 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]
| ||||||
| TransactionFailure | ||||||
|---|---|---|---|---|---|---|
Description[edit]
TransactionFailures represent failures during the execution of transactions, caused by conflicts or otherwise database related reasons. On the one hand side, a reasonable application might not only want but actually should catch them, on the other hand side they might be thrown in each and every modification related method, i.e. means in many methods.
Therefore it is extremely unhandy to declare those exceptions at all those methods - a classical match for the java RuntimeException. Furthermore, emphasising the special nature of TransactionFailures, they should even not be catched directly at the methods throwing them, because the invoker does not have enough information to know how to handle the exception, he might even not know that he's involved in a transaction.
So, where are those exceptions to be catched? The correct answer to this question is "the transaction boundary", a concept not existing in programming languages like java. This boundary is a closure (not modeled) around all possible entry points (method invocations) into an object aggregate currently participating with an ongoing transaction. Much care must be taken to keep this closure really closed, or alternative, tools like code generators might be used to guarantee it (thereby augmenting language behaviour).
Unfortunately, as a consequence of the lack of lanugage support for such a concept, no warnings will be issued if TransactionFailures are not caught by the application, which will result in runtime failures.
