General requirements for exception handling
(R1) - Must be simple to understand and use.
(R2) - The exception code must not obscure understanding of the normal error-free operations. The
program will then be difficult to understand and maintain.
(R3) - Run-time overheads are incurred only when handling an exception.
(R4) - Exceptions detected both by the environment and the program should be treated uniformly.
That is, errors like trying to access null pointers and realizing that your program thinks 2 + 2 = 5 should
be handled through the same mechanism.
(R5) - The mechanism should allow recovery actions to be programmed
Modern exception handling
- The modern approach to exception handling is to integrate it as part of the
programming language - An exception can be either synchronous or asynchronous:
I. Synchronous - Raised as an immediate result of the error
II. Asynchronous - Raised some time after the error occurred
Four classes of exceptions
There are four classes of exceptions:
1. Environment/synchronous - Such as divide by zero
2. Program/synchronous - Assertion failure (typical, makes program crash)
3. Environment/asynchronous - Such as a power failure
4. Program/asynchronous - One process concluding that some other process
may not meet a deadline/terminate incorrectly
Asynchronous and synchronous exceptions
- Asynchronous exceptions are often called asynchronous notifications or signals
and are usually considered in the context of concurrent programming - Synchronous exceptions can be declared in two ways:
I. A constant name needing explicit declaration (Ada)
I. An object of particular type or class (Java, C++), which may or may not
need to be explicitly declared
The standard package
package Standard is
…
Constraint_Error : exeception;
Program_Error : exeception;
Storage_Error : exeception;
Tasking_Error : exeception;
…
end Standard;
ADA example.
In a block structured language, like Ada, the domain is normally the block, here the Ada
block defines the temperature to be an integer between 0-100, if the value falls outside
the range, Ada raises the Constraint_error exception.
So the run-time support system of Ada causes exceptions like the following to be caught:
declare
subtype Temperature is Integer range 0 . . 100;
begin
– read temperaturesensor and calculate its value
exception
– handler for Constraint_error
end;
ADA example..
declare
subtype Temperature is Integer range 0 . . 100;
subtype Pressure is Integer range 0 . . 50;
subtype Flow is Integer range 0 . . 200;
Begin
begin
– read temperaturesensor and calculate its value
exception
– handler for Constraint_error for temperature
end;
begin
– read pressure sensor and calculate its value
exception
– handler for Constraint_error for pressure
end;
begin
– read flow sensor and calculate its value
exception
– handler for Constraint_error for flow
end;
– adjust temperature, pressure and flow to its required value
exception
– handler for other possible exceptions
end;
Exception propagation.
- Even if an exception is raised, we cannot guarantee that there is a handler
associated with the block in question - While often due to a programming error, sometimes the exception just
can’t be handled from inside the procedure in which it occurs
Exception propagation..
- Look for handlers up the chain of invokers; this is called propagating the exception
- The chain of function callers is looked up at run-time to find an appropriate
handler - If an exception is propagated outside its scope, then a ‘catch-all’ exception
handler can be used - Most languages provide a catch all exception handler
- An unhandled exception causes a sequential program to terminate
Resumption versus termination model
Should the invoker of the exception continue its execution after the exception has
been handled?
* Resumption model:
- If the invoker can continue, then it may be possible for the handler to cure the problem that
caused the exception to be raised and for the invoker to resume as if nothing has happened
This is referred to as the resumption or notify model
* Termination model:
- The model where control is not returned to the invoker, is called termination or escape
* Hybrid model:
- Clearly it is possible to have a model in which the handler can decide whether to resume the
operation which caused the exception, or to terminate the operation; this is called the hybrid
model
The resumption model.
Consider the procedures P; Q and R.
1) P invokes Q
2) Q invokes R
- Then an exception R is raised
3) Q has a handler Hr for R
4) Hr raises an exception q
5) P has a handler Hq for q
- Then, when q has been handled:
6) Hr continues to execute, handles R
R continues to execute
(fig 1)
The resumption model..
- Problem: it is difficult to repair errors raised by the Real time system.
- Erg, an arithmetic overflow in the middle of a sequence of complex
expressions results in registers containing partial evaluations; calling the
handler overwrites these registers
The resumption model…
- Implementing a strict resumption model is difficult, a compromise is to re-
execute the block associated with the exception handler - The advantage of the resumption model comes when the exception has
been raised asynchronously and, therefore, has little to do with the current
process execution
The termination model.
- In the termination model, when an exception has been raised, and the handler has been called,
control does not return to the point where the exception occurred. - Instead the block or procedure containing the handler is terminated, and control passed to
the calling block or procedure.
Example:
declare
subtype Temperature is Integer range 0 .. 100;
begin
…
begin
– read temperature sensor and calculate its value,
– may result in an exception being raised
exception
– handler for Constraint_Error for temperature,
– once handled this block terminates
end;
– code here executed when block exits normally
– or when an exception has been raised and handled.
exception
– handler for other possible exceptions
end;
The termination model.
fig 1
Exception Handling in Ada
- Ada supports: explicit exception declaration, the termination model, propagation
of unhandled exceptions, and a limited form of exception parameters. - Exception declared: either by language keyword:
stuck_valve : exception; - or by the predefined package Ada.Exceptions which defines a private type
called Exception_Id - Every exception declared by keyword has an associated Exception_Id which
can be obtained using the pre-defined attribute Identity
Raising an Exception
Exceptions may be raised explicitly
begin
…
– statements which request a device to
– perform some I/O
if IO_Device_In_Error then
raise IO_Error;
end if; – no else,as no return from raise
…
end;
* If IO_Error was of type Exception_Id, it would have been necessary to use
Ada.Exceptions.Raise_Exception; this would have allowed a textual string
to be passed as a parameter to the exception.
* Each individual raising of an exception is called an exception occurrence
* The handler can find the value of the Exception_Occurrence and used it to determine
more information about the cause of the exception
Exception handling.
- Optional exception handlers can be declared at the end of the block (or subprogram, accept statement or task)
- Each handler is a sequence of statements
declare
Sensor_High, Sensor_Low, Sensor_Dead : exception;
begin – statements which may cause the exceptions
exception
when E: Sensor_High | Sensor_Low =>
– Take some corrective action
– if either sensor_high or sensor_low is raised.
– E contains the exception occurrence
when Sensor_Dead =>
– sound an alarm if the exception sensor_dead is raised
end;
Exception handling..
when others is used to avoid enumerating all possible exception names
* Only allowed as the last choice and stands for all exceptions not previously listed
declare
Sensor_High, Sensor_Low, Sensor_Dead: exception;
begin
– statements which may cause exceptions
exception
when Sensor_High | Sensor_Low =>
– take some corrective action
when E: others => // last wishes
Put(Exception_Name(E));
Put_Line(“ caught. Information is available is “);
Put_Line(Exception_Information(E));
– sound an alarm
end;
Exception propagation
- If there is no handler in the enclosing block/subprogram/ accept statement, the
exception is propagated - For a block, the exception is raised in the enclosing block, or subprogram.
- For a subprogram, it is raised at its point of call
- For an accept statement, it is raised in both the called and the calling task
Difficulties with the Ada model of Exceptions.
- Exceptions and packages
- Exceptions which are raised a package are declared its specification
- It is not known which subprograms can raise which exceptions
- The programmer must resort to enumerating all possible exceptions every
- time a subprogram is called, or use of when others
- Writers of packages should indicate which subprograms can raise which
exceptions using comments
Difficulties with the Ada model of Exceptions..
- Parameter passing
- Ada only allows strings to be passed to handlers
- Scope and propagation
- Exceptions can be propagated outside the scope of their declaration
- Such exception can only be trapped by when others
- They may go back into scope again when propagated further up the dynamic
chain; this is probably inevitable when using a block structured language and
exception propagation
Recovery Blocks and Exceptions
Recall (Chapter 3.6)
ensure <acceptance>
by</acceptance>
<primary>
else by
<alternative>
else by
<alternative>
...
else by
<alternative>
else error
* Error detection is provided by the acceptance test; this is simply the negation of a test
which would raise an exception
* The only problem is the implementation of state saving and state restoration
</alternative></alternative></alternative></primary>
A Recovery Cache
- In the example below is shown a Ada package which implements a
recovery cache.
package Recovery_Cache is
procedure Save; – save volatile state
procedure Restore; –restore state
procedure Discard; – discard the state
end Recovery_Cache;
For sure, the body may require support from the run-time system and possibly
even hardware support for the recovery cache.
