In article <3b7cd493_1@dnews>
	"Kristofer Skaug" <✉satserv.nl> wrote:

> 
> "Barry Kelly" <✉eircom.net> wrote in message
> news:✉4ax.com...
> >
> > Exceptions are mechanisms of error *information* propagation. They do
> > not increase error. They do not spread error.
> 
> They are likely to increase and spread error if not intercepted,

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

> depending on the way you program around them.

Don't program around them! Use them.

>  The caller is forced to
> take special measures so as not to be adversely affected by exceptions.

No they aren't; only if their state isn't automatically rolled-back
through unwinding.


And if their state isn't automatically rolled-back, then that's a
problem with the programmer; 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.

> > Good. Then you shouldn't be opposed to exceptions, because exceptions
> is
> > a means of propagation of error information, not an error condition.
> 
> If this were all that they do, program 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. If errors are
normal program events for the domain in question, then exceptions
shouldn't be used (this is why I feel database "errors" probably
shouldn't use exceptions).


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


-- Barry