In article <3b7d7ea6_2@dnews>
"Kristofer Skaug" <✉skaug.demon.nl> wrote:
> <humor> THE DEBATE FROM HELL PART XIV </humor>
LOL!
> 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.
I'd never suggest re-raising an exception if you didn't know where it is
going to go. Of course you must be aware of where it's off to; whether
to notify the user, or enter a logging system or whatever.
> 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.
Of course. This is what I mean by transactional programming. Roll-back
or commit. Always leave the system in a valid state, assuming that
exceptions can happen anywhere.
> If you are implementing a program according to these principles, I
> believe that there is little or no added value in using exceptions.
Woah! Exceptions are valuable:
1) They force error-handling; that is, they prevent code from blundering
on regardless of errors. This, in my book, is a lot worse than simply
crashing out.
2) They unify error-handling into one mechanism. This is both useful
(errors are self describing, are object oriented and thus can use
polymorphism etc.) and not so useful (forces one size fits all policy).
> In
> fact, I maintain that the exception mechanism puts such programs at
> extra, needless risk.
You seem to believe that the risk of letting a program continue in the
face errors to be a virtue, if you are opposed to exceptions like this!
> "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;
Then let us have partial rollback; however, it is vital that the system
is in a consistent state after the exception has been ultimately caught.
> unless you want to add
> so many layers of try-finally that your performance suffers beyond
> reason.
There are ways of getting around this; consider the pattern:
a := TA.Create;
try
b := TB.Create;
try
// use a & b
finally
b.Free;
end;
finally
a.Free;
end;
transformed into
b := nil;
a := TA.Create;
try
b := TB.Create;
// use a & b
finally
b.Free;
a.Free;
end;
thus removing an entire exception frame. The concept (put the state into
a simple valid condition, and make moving away from that condition a
transaction in itself; that is, make b := nil (i.e. a valid state), then
make the assignment (and proper execution of) TB.Create a transaction,
which, if aborted, will still leave the system in a valid state) can be
adopted to other circumstances.
> <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.
Of course. <g>
> > 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.
I feel like SHOUTING! That isn't what exceptions are about. Look:
a := TA.Create;
try
a.Stuff;
finally
a.Free;
end;
Guess what! The finally part has access to local state! Isn't that
amazing! You're just after saying:
> Except that rollback is a lot easier in the local context
> surrounding a function call
and that's exactly what we have!
> > 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.
A little at a time, IMO. Maybe it adds up; you still have to do the
thinking whether the errors occur through return codes or global
variables, though. At least exceptions force you to do it.
> 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.
I disagree; certainly, I don't know your exact domain, but fault
tolerance isn't trivial. However, I don't think exceptions make it
harder; in fact, I think they are better than other mechanisms, if only
because they hit you on the nose if you try and ignore an error
condition.
> 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.
I think such a tool would make for a lot of work when implementations
change to use different mechanisms, resulting in different exceptions.
-- Barry