9.   EXCEPTION HANDLING

A major design criterion for this language is that it contribute toward the reliability of the systems that it is used to develop. Toward this end, a language facility, called exception handling, is provided so that a user can gain control and take appropriate action when a runtime error occurs. Both user-defined and language-defined runtime errors can be handled this way.

There are three parts to exception handling: the definition of an exceptional condition, called an exception; the occurrence, or raising, of the exception; and the handling of the raised exception.

Exceptions are either language-defined (see Appendix D) or defined by the user in an exception declaration. Exception names follow normal scope rules. Exceptions are raised explicitly by the elaboration of a raise or reraise statement. Language-defined exceptions are also raised automatically when an exceptional condition occurs during elaboration. The handling of an exception is achieved by the guard statement, which allows the user to gain control when an exception is raised. The guard statement consists of two parts: a guarded body in which an exception might be raised; and a set of handlers which can handle exceptions raised in the guarded body. Separate handlers can be provided for specific exceptions, and a general handler can be provided for all exceptions not handled separately. When an exception having a handler is raised in the guarded body, the elaboration of the guarded body is terminated and the body of the handler is elaborated. Elaboration of the guard statement is completed when elaboration of the handler is completed.

Guard statements may be nested within one another. When an exception is raised, the guard statement containing the guarded body in which the exception is raised is examined first. If it does not contain a handler for that exception, then enclosing guard statements are examined for the appropriate handler, starting with the innermost. The guard statement selected must meet two criteria; it must contain a handler for this specific exception; and it must not contain a deferred declaration which contains the raised exception.

If no enclosing guard statement is found before an enclosing deferred declaration is found, for all deferred declarations except tasks, the search for a handler for the exception continues in the scope containing the invocation of the deferred unit. In the case of tasks, the task activation is terminated and no further searching occurs.

If the search for a handler causes completion of elaboration of the scope in which the exception name is defined, the exception name is changed to X_UNHANDLED and the search for the X_UNHANDLED exception begins.

It is possible, within a handler, to reraise the exception which caused the elaboration of the handler. This allows a local action to be taken before searching resumes for another handler for the same exception.

When efficiency of generated code is more important than the guarantee of reliability, the suppress pragmat can be used to suppress the raising of exceptions (see Appendix B).

9.1  EXCEPTION NAMES

C - identifier

Exception names are defined by the exception declaration.

RULES

Each identifier is defined as an exception in the scope immediately containing the exception declaration.

NOTES

     Exception names have the same scope rules as all other names (see Section 3.5).

     Language-defined exceptions (see Appendix D) are predefined. No user-written exception declaration is needed.

EXAMPLES

EXCEPTION stack_overflow, stack_underflow;

9.2  GUARD STATEMENT

C - identifier   2 - body

A guard statement allows the user to gain control and take appropriate action when an exception is raised.

RULES

Each identifier between WHEN and => must be known as an exception. All identifiers in a guard statement must be distinct.

Body 1 is known as the guarded body of the guard statement. Each body 2 is a handler for the list of exceptions following the preceding WHEN. Body 3 following ELSE => is a handler for all exceptions not otherwise handled.

Elaboration of a guard statement consists of elaboration of the guarded body.

RED RATIONALE The syntactic similarity with the CASE and WAIT statements is intentional, since the three statements perform tasks that are conceptually similar.

NOTES

     An exception may only be explicitly referenced in a guard statement if the guard statement is in a scope in which the exception name is known.

     The semantics for finding a handler when an exception is raised is described in Section 9.3.

EXAMPLES

9.3  RAISE STATEMENT

C - identifier

The raise statement can be used to raise an exception.

RULES

The identifier must be known as an exception.

When an exception is raised, a search is made for the smallest enclosing:

1. guarded body of a guard statement;

2. deferred declaration; or

3. body in which the exception is defined.

If the body of a guard statement is found, and that guard statement has a handler for that exception (either specifically or via an ELSE clause), elaboration of the guarded body is terminated and the handler for that exception is elaborated. If the guard statement does not have a handler for that exception, the elaboration of the guard statement is terminated, and that exception is reraised at the place where the guard statement appears.

If a deferred declaration, which is not a task declaration is found, the invocation of the deferred declaration is terminated, and the exception is reraised at the point of invocation of the deferred unit.

If the body is found in which the exception is defined, the X_UNHANDLED exception is raised.

NOTES

     An exception may only be raised where its name is known. Certain langauge-defined operations may raise language-defined exceptions.

     The translator will issue a warning message if it discovers that an exception will always be raised at runtime. The translator will produce a list for each deferred declaration of exceptions which could be raised but not handled when that deferred declaration is invoked. It is possible to raise the X_TERMINATE exception in another activation (see Section 10.2).

EXAMPLES

1. Handling an exception raised in an invoked function.

   

   
   
   

2. Given two procedures, action1 and action2, which both do the same thing; first try action 1 and, if it fails, then try action2.

   

   
   
   

3. Changing to a more meaningful exception.

   

9.4  RERAISING EXCEPTIONS

The reraise statement permits some action, such as clean-up or statistics gathering, to be taken when an exception is raised, before the exception propagates outside the guard statement.

RULES

The reraise statement must be contained in the body of a handler of a guard statement.

Elaboration of the reraise statement is equivalent to elaboration of

    RAISE x;

where x is the exception being handled.

RED RATIONALE Using the RAISE statement with no exception specified was considered (in the interest of reducing the number of reserved words) but was rejected on reliability grounds. when initially sketching out code, a programmer could easily write in the beginning of a RAISE statement, intending subsequently to fill in the actual exception name. Omission of such details is a common coding problem and one of the main motivations for not allowing default declarations. The separate reraise syntax guarantees that the same exception will be reraised only if the programmer really intended that to happen.

NOTES

     Since an exception must be raised during elaboration of a guarded body of a guard statement in order to be handled by the handler of that guard statement, the reraising of an exception in a handler does not cause recursive elaboration of the same handler.

EXAMPLES

1. How to do local cleanup when an exception is raised.

   

   
   
   

2. How to retry an action n times before failure occurs