Previous UML Classes Table of Contents UML Packages Next

12.3.23 ExceptionHandler



   • Element (from Kernel ) on page 63


   An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node.


Issue 8240 - add subsets constraint


Issue 8481 -correct constraint text and add new constraint

   [1] The exception handler and its input object node are not the source or target of any edge.

   [2] An edge that has a source in an exception handler structured node must also have its target in the handler, and vice versa.

   [3] The result pins of the exception handler body must correspond in number and types to the result pins of the protected node.

   [4] The handler body has one input, and that input is the same as the exception input.


Issue 8729 -insert sentence about multiple matches

   If a RaiseExceptionAction is executed, all the tokens in the immediately containing structured node or activity are terminated. Then the set of execution handlers on the structured node or invocation action of the activity is examined for a handler that matches the exception. A handler matches if the type of the exception is the same as or a descendant of one of the exception classifiers specified in the handler. If there is a match, the handler catches the exception. If there are multiple matches, exactly one handler catches the exception, but it is not defined which does. The exception object is placed in the exceptionInput node as a token to start execution of the handler body.

Issue 8730 -insert more explanations about asynchronous and synchronous cases

   If the exception is not caught by any of the handlers on the node or invocation action, the exception handling process repeats, propagating to the enclosing structured node or activity. If the exception is not caught there, and the action that invoked the activity is asynchronous, the exception is lost, because the connection to the invoker is broken. If the action that invoked the activity is synchronous, the exception propagates up to that action. The process of exception propagation recurs until the exception is caught, or reaches the topmost level of the system. If the exception propagates to the topmost level of the system and is not caught, the behavior of the system is unspecified. Profiles may specify what happens in such cases.

   The handler body has no explicit input or output edges. It has the same access to its surrounding context as the protected node. The result tokens of the handler body become the result tokens of the protected node. Any control edges leaving the protected node receive control tokens on completion of execution of the handler body with the handler catching the exception. When the handler body completes execution, it is as if the protected node had completed execution.

Issue 8739 -add paragraph about completion

   When an expansion region is complete, tokens in the input expansion node and pins are removed.


    The notation for exception handlers is illustrated in Figure 12.79. An exception handler for a protected node is shown by drawing a lightning bolt symbol from the boundary of the protected node to a small square on the boundary of the exception handler. The name of the exception type is placed next to the lightning bolt. The small square is the exception input node, and it must be owned by the handler body. Its type is the given exception type. Both the protected node and the exception handler must be at the same nesting level. (Otherwise the notation could be misinterpreted as an interrupting edge, which crosses a boundary.) Multiple exception handlers may be attached to the same protected node, each by its own lightning bolt.

Issue 8279 - fix pin notation


   Figure 12.79 - Exception Handler Notation

*Presentation Options

Issue 8240 - replace ‘interrupting edge’ with ‘exception handler’

   An option for notating an exception handler is a zig-zag adornment on a straight line.

   Figure 12.80 - Exception Handler Presentation option


    Figure 12.81 shows a matrix calculation. First a matrix is inverted, then it is multiplied by a vector to produce a vector . If the matrix is singular, the inversion will fail and a SingularMatrix exception occurs. This exception is handled by the exception handler labeled SingularMatrix, which executes the region containing the SubstituteVector1 action. If an overflow exception occurs during either the matrix inversion or the vector multiplication, the region containing the SubstituteVector2 action is executed.

   The successors to an exception handler body are the same as the successors to the protected node. It is unnecessary to show control flow from the handler body. Regardless of whether the matrix operations complete without exception or whether one of the exception handlers is triggered, the action PrintResults is executed next.

Figure 12.81 - Exception Handler example


*Changes from previous UML

   ExceptionHandler replaces JumpHandler in UML 1.5.

   Modeling of traditional break and continue statements can be accomplished using direct control flow from the statement to the control target. UML 1.5 combined the modeling of breaks and continues with exceptions, but that is no longer necessary and it is not recommended in this specification.