14.2 Exception Handling in Ada

Exception handlers have the following general form, given here in EBNF:

when exception_choice {| exception_choice} => statement_sequence

Recall that the braces are metasymbols that mean that what they contain may be left out or repeated any number of times. The exception_choice has the form

exception_name | others

The exception_name indicates a particular exception that this handler is meant to handle. The statement sequence is the handler body. The reserved word others indicates that the handler is meant to handle any exceptions not named in any other local handler.

Exception handlers can be included in blocks or in the bodies of subprograms, packages, or tasks. Regardless of the block or unit in which they appear, handlers are gathered together in an exception clause, which must be placed at the end of the block or unit. For example, the usual form of an exception clause is shown in the following:

begin

-- the block or unit body -- exception

when exception_name1 => -- first handler --

when exception_name2 =>

--second handler --

--other handlers --

end;

Any statement that can appear in the block or unit in which the handler appears is also legal in the handler.

14.2.2Binding Exceptions to Handlers

When the block or unit that raises an exception includes a handler for that exception, the exception is statically bound to that handler. If an exception is raised in a block or unit that does not have a handler for that particular exception, the exception is propagated to some other block or unit. The way exceptions are propagated depends on the program entity in which the exception occurs.

When an exception is raised in a procedure, whether in the elaboration of its declarations or in the execution of its body, and the procedure has no handler for it, the exception is implicitly propagated to the calling program unit at the point of the call. This policy is reflective of the design philosophy that exception propagation from subprograms should trace back through the control path (dynamic ancestors), not through static ancestors.

If the calling unit to which an exception has been propagated also has no handler for the exception, it is again propagated to that unit’s caller. This

continues, if necessary, to the main procedure, which is the dynamic root of every Ada program. If an exception is propagated to the main procedure and a handler is still not found, the program is terminated.

In the realm of exception handling, an Ada block is considered to be a parameterless procedure that is “called” by its parent block when execution control reaches the block’s first statement. When an exception is raised in a block, in either its declarations or executable statements, and the block has no handler for it, the exception is propagated to the next larger enclosing static scope, which is the code that “called” it. The point to which the exception is propagated is just after the end of the block in which it occurred, which is its “return” point.

When an exception is raised in a package body and the package body has no handler for the exception, the exception is propagated to the declaration section of the unit containing the package declaration. If the package happens to be a library unit (which is separately compiled), the program is terminated.

If an exception occurs at the outermost level in a task body (not in a nested block) and the task contains a handler for the exception, that handler is executed and the task is marked as being completed. If the task does not have a handler for the exception, the task is simply marked as being completed; the exception is not propagated. The control mechanism of a task is too complex to lend itself to a reasonable and simple answer to the question of where its unhandled exceptions should be propagated.

Exceptions can also occur during the elaboration of the declarative sections of subprograms, blocks, packages, and tasks. When such exceptions are raised in procedures, packages, and blocks, they are propagated exactly as if the exception were raised in the associated code section. In the case of a task, the task is marked as being completed, no further elaboration takes place, and the built-in exception Tasking_Error is raised at the point of activation for the task.

14.2.3Continuation

In Ada, the block or unit that raises an exception, along with all units to which the exception was propagated but that did not handle it, is always terminated. Control never returns implicitly to the raising block or unit after the exception is handled. Control simply continues after the exception clause, which is always at the end of a block or unit. This causes an immediate return to a higher level of control.

When deciding where execution would continue after exception handler execution was completed in a program unit, the Ada design team had little choice, because the requirements specification for Ada (Department of Defense, 1980a) clearly states that program units that raise exceptions cannot be continued or resumed. However, in the case of a block, a statement can be retried after it raises an exception and that exception is handled. For example, suppose a statement that can raise an exception and a handler for that exception are both enclosed in a block, which is itself enclosed in a loop. The following

example code segment, which gets four integer values in the desired range from the keyboard, illustrates this kind of structure:

...

type Age_Type is range 0..125;

type Age_List_Type is array (1..4) of Age_Type; package Age_IO is new Integer_IO (Age_Type); use Age_IO;

Age_List : Age_List_Type;

...

begin

for Age_Count in 1..4 loop

loop -- loop for repetition when exceptions occur

Except_Blk:

begin -- compound to encapsulate exception handling

Put_Line("Enter an integer in the range 0..125");

Get(Age_List(Age_Count));

exit; exception

when Data_Error => -- Input string is not a number Put_Line("Illegal numeric value");

Put_Line("Please try again");

when Constraint_Error => -- Input is < 0 or > 125 Put_Line("Input number is out of range"); Put_Line("Please try again");

end Except_Blk;

end loop; -- end of the infinite loop to repeat input -- when there is an exception

end loop; -- end of for Age_Count in 1..4 loop

...

Control stays in the inner loop, which contains only the block, until a valid input number is received.

14.2.4Other Design Choices

There are four exceptions that are defined in the default package, Standard:

Constraint_Error

Program_Error

Storage_Error

Tasking_Error

Each of these is actually a category of exceptions. For example, the exception Constraint_Error is raised when an array subscript is out of range, when there is a range error in a numeric variable that has a range restriction, when a

reference is made to a record field that is not present in a discriminated union, and in many other situations.

In addition to the exceptions defined in Standard, other predefined packages define other exceptions. For example, Ada.Text_IO defines the End_Error exception.

User-defined exceptions are defined with the following declaration form:

exception_name_list : exception

Such exceptions are treated exactly as predefined exceptions, except that they must be raised explicitly.

There are default handlers for the predefined exceptions, all of which result in program termination.

Exceptions are explicitly raised with the raise statement, which has the general form

raise [exception_name]

The only place a raise statement can appear without naming an exception is within an exception handler. In that case, it reraises the same exception that caused execution of the handler. This has the effect of propagating the exception according to the propagation rules stated previously. A raise in an exception handler is useful when one wishes to print an error message where an exception is raised but handle the exception elsewhere.

An Ada pragma is a directive to the compiler. Certain run-time checks that are parts of the built-in exceptions can be disabled in Ada programs by use of the Suppress pragma, the simple form of which is

pragma Suppress(check_name)

where check_name is the name of a particular exception check. Examples of such checks are given later in this chapter.

The Suppress pragma can appear only in declaration sections. When it appears, the specified check may be suspended in the associated block or program unit of which the declaration section is a part. Explicit raises are not affected by Suppress. Although it is not required, most Ada compilers implement the Suppress pragma.

Examples of checks that can be suppressed are the following: Index_ Check and Range_Check specify two of the checks that are normally done in an Ada program; Index_Check refers to array subscript range checking; Range_Check refers to checking such things as the range of a value being assigned to a subtype variable. If either Index_Check or Range_Check is violated, Constraint_Error is raised. Division_Check and Overflow_ Check are suppressible checks associated with Numeric_Error. The following pragma disables array subscript range checking:

pragma Suppress(Index_Check);

There is an option of Suppress that allows the named check to be further restricted to particular objects, types, subtypes, and program units.

14.2.5An Example

The following example program illustrates some simple uses of exception handlers in Ada. The program computes and prints a distribution of input grades by using an array of counters. The input is a sequence of grades, terminated by a negative number, which raises a Constraint_Error exception because the grades are Natural type (nonnegative integers). There are 10 categories of grades (0–9, 10–19, . . . , 90–100). The grades themselves are used to compute indexes into an array of counters, one for each grade category. Invalid input grades are detected by trapping indexing errors in the counter array. A grade of 100 is special in the computation of the grade distribution because the categories all have 10 possible grade values, except the highest, which has 11 (90, 91, . . . , 100). (The fact that there are more possible A grades than B’s or C’s is conclusive evidence of the generosity of teachers.) The grade of 100 is also handled in the same exception handler that is used for invalid input data.

--Grade Distribution

--Input: A list of integer values that represent

--grades, followed by a negative number

--Output: A distribution of grades, as a percentage for

--each of the categories 0-9, 10-19, ...,

--90-100.

with Ada.Text_IO, Ada.Integer.Text_IO; use Ada.Text_IO, Ada.Integer.Text_IO; procedure Grade_Distribution is

Freq: array (1..10) of Integer := (others => 0);

New_Grade : Natural;

Index,

Limit_1,

Limit_2 : Integer; begin

Grade_Loop:

loop

begin -- A block for the negative input exception Get(New_Grade);

exception

when Constraint_Error => -- for negative input exit Grade_Loop;

end; -- end of negative input block Index := New_Grade / 10 + 1;

begin -- A block for the subscript range handler Freq(Index) := Freq(Index) + 1;

exception

-- For index range errors when Constraint_Error =>

if New_Grade = 100 then

Freq(10) := Freq(10) + 1;

end Grade_Distribution;

Notice that the code to handle invalid input grades is in its own local block. This allows the program to continue after such exceptions are handled, as in our earlier example that reads values from the keyboard. The handler for negative input is also in its own block. The reason for this block is to restrict the scope of the handler for Constraint_Error when it is raised by negative input.

14.2.6Evaluation

As is the case in some other language constructs, Ada’s design of exception handling represents something of a consensus, at least at the time of its design (the late 1970s and early 1980s), of ideas on the subject. For some time, Ada was the only widely used language that included exception handling.

There are several problems with Ada’s exception handling. One problem is the propagation model, which allows exceptions to be propagated to an outer scope in which the exception is not visible. Also, it is not always possible to determine the origin of propagated exceptions.

Another problem is the inadequacy of exception handling for tasks. For example, a task that raises an exception but does not handle it simply dies.

Finally, when support for object-oriented programming was added in Ada 95, its exception handling was not extended to deal with the new constructs. For example, when several objects of a class are created and used in a block and