"Pete d'Oronzio" <✉pdmagic.com> wrote in message
news:3b7867a6$1_2@dnews...

> For me, the benefit of using exceptions, is that I don't have to figure out
> what went wrong when updating the time stamp.  If the UpdateTimeStamp
> routine throws an exception, I can ignore it, and let the program terminate;
> or I can catch it, log it and keep going; or I can catch it, change the
> read-only attribute, call it again, and then keep going.  That's why I've
> been leaning towards an 'exceptions for everything' approach.

I don't see how or why any of the above would be more difficult
without
raising exceptions. On the contrary.
But, let me elaborate a little on the statement I made above:

> ...exceptions are really contrary to the
> philosophy of error containment.

What I mean here, is not that you *can't* contain exceptions (because
you *can*, by catching them early); however, exceptions are inherently
mechanisms of error propagation, and the programming style associated
with this mechanism encourages such propagation.
In my line of business (spacecraft and ground systems), failure
detection, isolation, containment and recovery is the highest good.
Any fault propagation is considered evil and should be constrained to
the maximum possible extent (note: I am talking about propagation of
the error *condition*, not about error *messages*). Writing an
exception-based program is contrary to this principle. This maybe a
slightly 'anal' and conservative attitude but it's one I can very well
live with.


Kristofer