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

From OOModels
< Artefact:Model‎ | com‎ | sphenon‎ | basics‎ | exception
Jump to navigationJump to search
(New page: {{Metabox | Meta_Type = Type:org/oomodels/WIML/1.0 | Meta_Domain = Domain:it/test | Meta_Category = Type:org/oomodels/wiki/Model | Meta_Downloa...)
 
 
(One intermediate revision by the same user not shown)
Line 18: Line 18:
== Description ==
== Description ==


[[Artefact:Model/com/sphenon/basics/exceptions/ReturnCode|TransactionFailure]]s represent
[[Artefact:Model/com/sphenon/basics/exception/TransactionFailure|TransactionFailure]]s represent
failures during the execution of transactions, caused by conflicts or otherwise database
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
related reasons. On the one hand side, a reasonable application might not only want but

Latest revision as of 09:57, 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.RuntimeException
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.