"Raoul De Kezel" <✉hotmail.com> wrote in message news:MPG.email@example.com nprise.com...
> > The paper is available at
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.