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