"Raoul De Kezel"
<✉hotmail.com> wrote in
message
news:MPG.15e0fcd333d3013e989730@forums.i
nprise.com...

>
> The paper is available at

ftp://ftp.cs.ucsd.edu/pub/team/exception
handling.ps.Z

>

Raoul,


I've taken some time to read that paper
and although I skipped some of the more
mathematical parts of it, it *did* give
me a refreshing perspective on the issue
of exceptions. Here's one highlight:
<quote, p.28>
The notion of an exception is defined
[...] to mean "impossibility of
obtaining the specified standard
service". It therefore depends on how
the states of a program are defined and
how the standard service of that program
is specified."
</quote>
My interpretation: The designer of a
program, or function, or block of code,
*implicitly* determines the criteria for
raising exceptions; this is because the
purpose of the exception is to:


a) signal impossibility to produce a
normal correct result
b) prevent the program/function/code
block from returning an invalid result
which will screw up the rest of the
system


The important factor here being accurate
*specification* of the behaviour of the
code, both for nominal and failure
cases.
Also, an important point in this article
is that free propagation of exceptions
across the call stack is a threat to
program stability unless you are able to
recover states in your intermediate
objects (or your objects are stateless).
The same cannot be said of error codes
since they do not automatically
propagate.


Kristofer