🚀 go-pugleaf

In article <DJ35vK.39x@falcon.daytonoh.attgis.com> Dick Menninger
<Dick.Menninger@daytonoh.attgis.com> writes:

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

I think we basically agree.  Exceptions do not solve any design
problems in error handling strategy; they are an implementation tool,
which may possibly simplify the implementation of the strategy once
the strategy has been decided upon.  In the past, I have seen far to
many people pretending that with exceptions, all problems with error
handling and error reporting will disappear.

I think it must also be made clear that the "reduced distortion" comes
at a price.  Exceptions have certain dangers (much the same ones as
goto).  Much has been said about resource leaks, and how to handle
them.  My only point in the above is that this is not the only danger
you must pay attention to.  Typically, you program invariants are
invalid in significant blocks of code, since changes from on invariant
consistent state to another are not atomic.  (As a typical example,
class invariants will often not hold at certain points in member
functions of the class.)  Exception safety must also ensure that all
invariants *do* hold if the exception percolates up to a level at
which it is expected that they hold.

With regards to your comments, I do wonder if the fact that error
handling distorts your code is in some way a sign that your design did
not consider error recovery as a first class problem, at the same
level as all other possible behaviors.  (I also wonder if maybe
exceptions aren't "too naively simple", as you put it.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone



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