Barry Kelly
Re: Exceptions vs Error codes

Re: Exceptions vs Error codes


Before addressing any of your responses specifically, I just need to take 2 steps back and remind myself of the following: It is not the exceptions as such that I object to; I see how they have their uses. *BUT*: it is also a question of coding strategy (bottom-up vs. top-down responsibility delegation). For *fault tolerant systems*, which is what I am considering when I talk, perhaps sometimes implicitly without mentioning it, *fault containment* is a very important quality of a program. This means that you really need to trap all exceptions as early as possible and prevent them from bubbling up in uncontrolled fashion to the application default exception handler. Unrecoverable errors (=failures), signalled in the form of exceptions, should never lead to uncontrolled shutdown but allow a graceful degradation of the system so that as much as possible can be salvaged, saved, restored or closed down in a controlled manner. If you are implementing a program according to these principles, I believe that there is little or no added value in using exceptions. In fact, I maintain that the exception mechanism puts such programs at extra, needless risk.
Now for the debate at hand:
"Barry Kelly" <‚úČ> wrote in message

> Use try..finally (or possibly try..except {do something}; raise end) to
> enforce transaction-like behaviour.

Clearly that's our best hope, yes, but even with try-finally a full
rollback can be nearly impossible in some cases; unless you want to add
so many layers of try-finally that your performance suffers beyond

> And if their state isn't automatically rolled-back, then that's a
> problem with the programmer;

<G>, undesirable program behaviour is usually the programmer's fault

> what's more, it *has nothing to do with exceptions*, because the
> programmer should provide this behaviour *even when error
> conditions are flagged through return values*, or global variables,
> or any other mechanism.

Except that rollback is a lot easier in the local context surrounding a
function call, than it is to perform an equivalent rollback (or retry, or
whatever) in some higher-level exception handler potentially completely
out of the scope of most state variables which need restoring. That's

> > execution should simply return to
> > the next line of code after an exception.
> That would be the worst possible case, IMO (of all implementable
> error mechanisms).
> > Exceptions are not simply
> > "events" which carry some error information; they interrupt normal
> > program flow and thus potentially wreak havoc unless extreme care is
> > taken.
> That's because errors aren't normal program events, and continuing as if
> everything was normal would be even more catastrophic.

I didn't say to "continue as normal". I just want control back so I can
evaluate what to do. I don't want someone else's 'generalised'
exception-raising philosophy (I don't mean you!) to decide this for me.

> If errors are normal program events for the domain in question, then
> shouldn't be used

that's one thing we agree on for sure. The problem comes with "generic"
code / component libraries which raise exceptions without knowledge of
the domain specifics (because, naturally, they have no clue what you
want!) You have to re-mold these to conform to your error handling

> And the care necessary isn't extreme; it just takes a little thought all
> the time. A little awareness, that's all.

Correction: A lot. If you are trying to create reliable systems then you
should: have a uniform error handling and - tolerance strategy (and
implementation approach) throughout the entire application, and carefully
evaluate each and every thinkable and unthinkable exception source and
how it might affect the state of your system. Exceptions make a tough job
even tougher.

Another thing: previously we discussed exception specifications. I don't like them as a language feature, but I *do* wish there was more support for precise specifications of functions. For example, an analyzer module in the Delphi compiler which could help you determine the nominal and exceptional domains of a function, as a documentation feature.
FYI: Phrase searches are enclosed in either single or double quotes
Originally created by
Tamarack Associates
Tue, 07 Feb 2023 04:52:48 UTC
Copyright © 2009-2023
HREF Tools Corp.