Digital

NAME

EXCEPTION HANDLER −  part of a task definition to which the ACMSxp system transfers control when an exception occurs
 

SYNOPSIS

 { <statement block> | <transaction block> }
 EXCEPTION HANDLER IS
 
   [ <assignment statement> | <audit statement> | <control field statement>
     | <exit task statement> | <get message statement> | <go to statement>
     | <if then else statement> | <raise exception statement>
     | <reraise exception statement> | <select first true of statement>
     | <while do statement> ] [ ... ]
 
   [ BLOCK WITH TRANSACTION
 
     [ <call presentation statement> | <call procedure statement>
       | <call task statement> | <cancel task submit statement>
       | <dequeue statement> | <enqueue record statement>
       | <exit block statement> | <exit task statement>
       | <read queue statement> | <restart transaction statement>
       | <submit task statement> ] [ ... ]
 
     END BLOCK ; ] [ ... ]
 
 END EXCEPTION HANDLER
 

PARAMETER

       •statement
 
A statement or statement list to execute as part of an exception handler. RERAISE can be used only in an exception handler. RESTART TRANSACTION is not allowed in a transaction exception handler.
 
Each statement must end with a semicolon (;).
 
Some statements must be used inside a transaction block. If such a statement is to be used in an exception handler, the statement must be enclosed by a transaction block inside the exception handler of a transaction block or of a statement block outside a transaction block.

DESCRIPTION

 
In STDL on an ACMSxp system using the multiple resource transaction model, all exceptions must be passed back to the task that controls a transaction. The exception handler receives control when an exception is raised in the task or is passed back to the task. The exception handler must be associated with either a statement block or a transaction block. Without either a statement block or a transaction block, a task cannot handle an exception.
 
Each exception handler has a scope, that part of the task for which the exception handler is executed in response to an exception. The scope of an exception handler can include parts of a task for which no exception handler is specified and differs for nontransaction exceptions and transaction exceptions.
 

Nontransaction Exception Handlers

 
A nontransaction exception handler handles only nontransaction exceptions and must be associated with a statement block that is:

oIn a composable task (always within the transaction of the caller)

oInside a transaction block (noncomposable task)

In a composable task, an exception handler can handle only nontransaction exceptions and must be associated with a statement block. (Transaction blocks are illegal in a composable task.) Only nontransaction exceptions can be handled because composable tasks do not demarcate or control transactions, but are part of the transaction controlled by a noncomposable task. 
 
In a noncomposable task, the only way to handle nontransaction exceptions is to have an exception handler associated with a statement block that is inside a transaction block.
 

Transaction Exception Handlers

 
A transaction exception handler handles transient and permanent transaction exceptions and must be associated with:

oA transaction block (noncomposable task)

oA statement block that is outside a transaction block (noncomposable task)

In a noncomposable task, an exception handler associated with a transaction block handles any transaction exceptions that occur within the transaction block. If the transaction block or blocks are contained within a statement block, the exception handler associated with the statement block handles transaction exceptions that occur within the enclosed block. 
 
The following summarizes the levels of exception handlers and describes their scope.
 

oStatement block in a composable task
 
Handles only nontransaction exceptions.

oStatement block inside a transaction block
 
Handles nontransaction exceptions that occur during a statement within the statement block. If a transaction exception is raised in the statement block, control passes to a transaction exception handler.

oTransaction block transaction block. 
 
Handles transient and permanent transaction exceptions that occur in the If a nontransaction exception is raised during a statement for which there is no exception handler, the system converts the exception to a transaction exception so that this handler can handle it.

oStatement block outside a transaction block
 
Handles transient and permanent transaction exceptions that occur in any transaction block for which there is no exception handler, or in a transaction block exception handler.

In noncomposable tasks, exception handlers can handle either nontransaction exceptions or transaction exceptions. 
 
The ACMSxp system can change exception types, depending on where they are raised. For example, if a called noncomposable task raises a permanent transaction exception, and has no applicable exception handler, the transaction is rolled back and the task canceled. ACMSxp software changes the exception type from permanent transaction to nontransaction, and returns the nontransaction exception to the calling task. If the calling task has no applicable exception handler, the exception is changed back to a permanent exception. See the exception man page. 
 
If the ACMSxp run-time system transfers control to an exception handler, the ACMSxp software considers the exception processing to be finished. The exception handler has access to the information in the EXCEPTION-INFO-WORKSPACE system workspace. The exception handler itself can raise an exception, if necessary, and can reraise an exception. The exception handler completes the execution of the statement with which the exception handler is associated.
 
If the ACMSxp system encounters a system-generated exception during the execution of a transaction exception handler, the exception is treated as a fatal transaction exception.
 

Exception Handler Coding

 
The task can check whether the source of the exception is the system or the application. For example:
 
 IF EXCEPTION-INFO-WORKSPACE.EXCEPTION-SOURCE = 0
   THEN
     GOTO handle_system
   ELSE
     GOTO handle_application
 END IF;
 
The contents of the exception information system workspace are accessible to the task when the exception handler gets control. The task can provide a conditional statement to determine whether the system raised the exception. The task can provide separate STDL statements or statement lists to handle system and application exceptions, for example, at the labels handle_system and handle_application.
 

Normal Flow

 
The normal execution flow for an exception handler is:

oInitialize the exception class, source, code, code group, level, and location fields within the EXCEPTION- INFO-WORKSPACE system workspace. 

oExecute the statement or statements in the handler. 

oComplete the exception handler with default flow control. 

Deviations from the normal execution flow occur when the statements complete with:

oExplicit flow control. If the processing specifies explicit flow control, the exception handler completes with the same explicit flow control. 

oException. If an exception is raised in the exception handler, the exception handler completes with that exception. 

EXCEPTIONS

 
The exception handler itself does not generate any exceptions.
 

RELATED INFORMATION

Syntax: exception(1), raise_exception(1), reraise_exception(1), restart_transaction(1), statement_block(1), transaction_block(1)

acmsxp_introduction(1)