> it *did* give me a refreshing perspective on the issue
> of exceptions

So did it for me :-)

> 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; 

True, but incomplete, IMO. The called function 
should ideally raise an exception when sequential 
execution of caller code is meaningless (because 
the standard service cannot be provided)


Now, the called function often *cannot* know whether
caller code prefer to handle some unusual condition
through sequential execution or exception handling.


Therefore, it is IMO good practice for a library to 
provide two standard services. A restricted one, with 
signals anticipated exceptional conditions through 
exceptions, and an extended one, where the result range 
is extended with exceptional codes or objects.


As a concrete example, I would call the restricted 
StrToInt when parsing back an ascii file my app did 
write, and expect an exception in strange cases. 
I would call StrToIntOrError when parsing user input,
expecting back an integer or a precise reason for 
the conversion failure.

> 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).

Soooo true, and one of the reasons to prefer error codes.


In 1989, it was already well known how important it
is to automatically put the system back in a consistent 
state when propagating exceptions. And more than a decade 
later most mainstream langages dont support this (and
dont support well a formal specification of anticipated 
exceptions, for that matter)


I used to program databases, which *do* automatically 
restore system state when an exception is propagated.
When I see a database exception, I am 110% sure that
the system is in a consistent state. When I see a
Pascal exception, I pray...

> The same cannot be said of error codes
> since they do not automatically
> propagate.

Sure. Error codes have a visibility that exceptions
dont have. That helps to prove correctness of propagation
or handling, and I certainly understand that people
working on critical software prefer error codes (in
languages without automated rollback)


--- Raoul