🚀 go-pugleaf

> ==========J. Kanze, 12/1/95==========
 
> Of course, with regards to exception safety, resource leaks are the
> least of your problems.  What happens if the exception causes you to
> leave the internal data in some inconsistent state, which results in an
> endless loop (because of a cycle in a graph, for example) the next time
> you access the data structure.

Help in avoiding resource leaks in the face of exceptional
conditions that are best served by major unfolding of the
stack back to some handling point is what exception are
about.  As such, they are potentially an advance over
setjump/longjump.  Error handling always has "distorted"
code and that is why so many programmers have ignored it.
Of course you have to design and code your algotithms
so that exception can happen only at "safe" (in terms of
data consistency) points or are caught locally enough to
repair that before letting the exception go through.
Exceptions still have the potential for handling these
error cases in the least distorting way possible.
But the key word is "possible".
I think people want handling errors to be easier
and less "distorting" than is feasible.
What you get is a mechanism that does not handle
real problems very well because it is too naively simple.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]