============================================
<humor> THE DEBATE FROM HELL PART XIV </humor>
============================================


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" <✉eircom.net> wrote in message
news:✉4ax.com...

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


<snip>

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

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

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

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

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

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


Kristofer