Article

From:
To:
Kristofer Skaug
Subject:
Re: Exceptions vs Error codes
Newsgroup:
borland.public.delphi.objectpascal

Re: Exceptions vs Error codes

> 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
FYI: Phrase searches are enclosed in either single or double quotes
 
 
Originally created by
Tamarack Associates
Wed, 09 Oct 2024 15:51:34 UTC
Copyright © 2009-2024
HREF Tools Corp.