Artefact:Model/com/sphenon/basics/exception/TransactionFailure - Revision history

AndreasLeue at 09:57, 26 March 2010

2010-03-26T09:57:58Z

← Older revision		Revision as of 09:57, 26 March 2010
Line 18:		Line 18:
	== Description ==		== Description ==

	[[Artefact:Model/com/sphenon/basics/~~exceptions~~/TransactionFailure\|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

AndreasLeue at 09:57, 26 March 2010

2010-03-26T09:57:22Z

← Older revision		Revision as of 09:57, 26 March 2010
Line 18:		Line 18:
	== Description ==		== Description ==

	[[Artefact:Model/com/sphenon/basics/exceptions/~~ReturnCode~~\|TransactionFailure]]s represent		[[Artefact:Model/com/sphenon/basics/exceptions/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

AndreasLeue: 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...

2010-03-26T09:56:35Z

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

New page

{{Metabox
| Meta_Type = Type:org/oomodels/WIML/1.0
| Meta_Domain = Domain:it/test
| Meta_Category = Type:org/oomodels/wiki/Model
| Meta_Download = true
| Meta_Diagram = Artefact:Diagram/com/sphenon/basics/exception/Exceptions
| Meta_AddTypeToCategory = true
| Meta_AddCategoryToCategory = true
}}

== Code ==

<wiml>
* TransactionFailure
> java.lang.RuntimeException
</wiml>

== Description ==

[[Artefact:Model/com/sphenon/basics/exceptions/ReturnCode|TransactionFailure]]s 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.