Exception Handling
and Tolerance of
Software Faults
Prepared by:
Saeid Pashazadeh
Written By: Flaviu Cristian
University of California,San Diego
(session 2)
The intended state transition that a program P should
perform when an anticipated exception e ЄE is
detected can be specified by an exceptional
specification Ge:
A pair of states (s,s') is in Ge if the intended outcome of
invoking P in the initial state s ЄS is to make P terminate
at its declared “e” exceptional exit point in the final state s'
Є S.
Exceptional Precondition
Exceptional Postcondition
Exceptional specification
Exceptional Semantics [P]e of a program P with respect to
an exception label e in X (either declared or undeclared for
P) is the function (from input to output states) that P
actually computes between its start and its termination at
the “e” exit point:
A pair of states (s,s') is in [P]e if, when invoked in the initial
state s in S, P terminates at its “e” exit point in the final state
s' 2 S
Program Failures, Faults, and
Errors
Consider a program P whose specification is structured into a
standard service Gσ and zero or more exceptional services
Ge, e Є E. The specification G of P is the set of all standard
and exceptional specifications defined for P:
Anticipated Inputs
Unanticipated Inputs
A specification is complete if it prescribes the behavior
of P for all possible input states s in S:
For instance, the specification GF={GFσ,GFnegative} is
not complete, since it does not specify the result to be
produced when FE is invoked with a positive argument
whose factorial is not machine representable. An
example of a complete specification is CGF = {
GFσ,GFnegative,Gfoverflow}
The semantics of a program P with exceptional exit
points X is the set of all semantic functions [P]x, x Є X U
{σ}, that P computes between a start and a termination
at some (declared or undeclared) exit point x:
A program P is termed totally correct with respect to a
specification G if its actual semantics [P] is consistent
with the intended semantics G:
Correctness does not necessarily imply that [P] and G
are equal
procedure RFE(in out n: Integer) signals negative, overflow;
var k,m: Integer;
begin
[n<0: signal negative];
k:=0; m:=1;
while k<n
do k:=k+1;
m:=m * k[intovflw: signal overflow]
od;
n:=m
end;
A program that is totally correct with respect to a
complete specification is robust, in that
its behavior is predictable for all possible inputs.
The procedure RFE is robust since its behavior is
correctly predicted by the specification CGF for all
possible initial values of n.
A robust program whose exceptional
specifications Ge, e Є E, are identity relations is
called atomic with respect to the exceptions e
ЄE.
If a program P is not totally correct with respect to a
specification G, there exist (anticipated)
input states s ЄAI for which P's behavior contradicts
G. The set of all input states for which
the actual behavior of P contradicts the specified
behavior G is the failure domain FD of P
with respect to G:
One can talk about a specification failure whenever
a specification fails to prescribe the program behavior
for some inputs, that is, whenever UI  {}.
Specification failures are in fact as annoying as
program failures.
A program failure occurs when a program is invoked
in its failure domain FD.
SD
AED
FD
UI
A failure of a sequential program P for an input s Є FD can
be of one the following four
types:
1) P loops indefinitely:
2) an exception u that was not declared for P is detected:
3) P terminates normally (i.e., at its standard exit point) in a
final state s' which does not
satisfy the standard specification of P:
4) P terminates by signalling a declared exception e Є E in a
final state s' which does not satisfy the exceptional
specification Ge :
Failures of type (1) or (2) are referred to as confined
failures, while failures of type (3) or (4) are referred to as
unconfined failures. Corresponding to these two general
failure classes, the failure domain FD can be divided into
a confined failure domain CFD, and an unconfined
failure domain UFD:
A program P which, for every input, either terminates
properly in a state satisfying the specification G or
suffers a confined failure will be termed partially correct
with respect to the specification G. In other terms, a
partially correct program is one that has empty UI and
UFD domains.
The interest in partially correct programs comes from
the fact that such programs are safe, in the sense
that they never output erroneous results to their
users.
partially correct programs can be used to build fail-safe
programs, that is, programs that either deliver a correct
output in a timely manner or otherwise deliver a predefined
output considered “safe” for the application at hand.
The occurrence of program failures can be attributed to the
existence of design faults. Thus, if the failure domain FD of
a program P with respect to a specification G is not empty,
one says that the program P has a design fault with
respect to the specification G.
For example, any invocation of the
program F (which is incorrect with respect
to the complete specification CGF) with an
initial value n such that n! is not machine
representable results in improper
termination of F. The absence of a handler
associated with the intovflw
language defined exception in Figure 4.1
is thus a design fault.
procedure FFE(in out n: Integer) signals negative;
var k,m: Integer;
begin
[n<0: signal negative];
k:=0; m:=1;
while k < n
do m:=m _ k;
k:=k+1;
od;
n:=m
end;
when the unconfined failure domain of a
program contains a state s such that,
when started in s, P terminates properly
at some declared exit point x in a final
state s” different from the intended final
state s' prescribed by the specificationGx
for s. Then there exist program variables v
whose state is erroneous, in that their
value s”(v) is different from the value s'(v)
prescribed by the specification Gx. The
value that such a variable v possesses in
s” is called an error (with respect to the
specification Gx).
The standard domain of FFE with
respect to the specification CGF is
}0{. Whenever
FFE is invoked with an actual
parameter that is strictly positive,
the final value of n (0) is an error
since it is different from the final
value prescribed by CGF.
EXCEPTION HANDLING IN
HIERARCHICAL MODULAR PROGRAMS


The basic problems to be solved at each
abstraction level, such as exception
detection, consistent state recovery,
exception masking and propagation are
discussed.
we assume that specifications are correct
and the lower level services on which a
hierarchical modular program depends are
also correctly functioning.
Hierarchical Program Structure




In the 70s, it became clear that data
abstraction is a powerful mechanism .
“abstract” and built-in “concrete” types.
hierarchy of modules
O, P, and Q as names for operations
exported by the modules L, M, and N,
respectively, and by using d, e, f as
generic exception names for the
operations O, P, and Q, respectively
Programmed Exception Handling