12.3.23 ExceptionHandler

*Generalizations

   • Element (from Kernel ) on page 63

*Description

   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.

*Associations

Issue 8240 - add subsets constraint

• protectedNode : ExecutableNode [1..1] The node protected by the handler. The handler is examined if an exception propagates to the outside of the node. {Subsets Element::owner}

• handlerBody : ExecutableNode [1..1] A node that is executed if the handler satisfies an uncaught exception.

• exceptionType : Classsifier [1..*] The kind of instances that the handler catches. If an exception occurs whose type is any of the classifiers in the set, the handler catches the exception and executes its body.

• exceptionInput : ObjectNode [1..1] An object node within the handler body. When the handler catches an exception, the exception token is placed in this node, causing the body to execute.

*Constraints

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.

*Semantics

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.

*Notation

    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

   ExceptionType

   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

*Examples

    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.

   SingularMatrix

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