TITLE: ramblings on the use of exceptions

(Newsgroups: comp.lang.c++.moderated)


Kevin: kjhopps@mmm.com (Kevin J Hopps)

|> >Can you provide a sample code fragment that is complicated with exceptions
|> >but is simple without exceptions?

Raoul: 100653.2230@compuserve.com (Raoul De Kezel)

|> In my answer to Andrew Bell, I gave an example of code which (I think)
|> is perfectly correct in an exception free environment, but fails when
|> an exception is thrown.

James: kanze@gabi-soft.fr (J. Kanze), 10 May 96

While I don't share Kevin's enthusiasm for exceptions, I don't think you
realize what he is getting at.  An exception which is thrown does
something, even in the functions it just passes through.  It propagates
an error up.  Considering your claims: does the function which is
`perfectly correct in an exception free environment' propagate errors
that occur beneath it?  If not, either you can prove that no errors may
occur beneath it (in which case, it is also exception safe, since no
errors == no exception), or it is broken.  And of course, it is not
surprising that a function which only provides a part of the required
functionality is simpler than one which provides all of it.

Just for the record, the problems I have with exceptions are largely
linked to the `proving no errors occur beneath it'.  Without exceptions,
this is simple: if none of the functions called in my function return
error codes, then no errors can occur beneath it.  (Unless, of course,
one of the functions it calls is broken, and ignores an error.  But
exceptions don't help here.  An ignored error is not going to trigger an
exception, any more than it will set a return code.)  With exceptions,
you never know.  Most importantly, with exceptions (and no binding
exception specifications), a function called by my function can start
generating errors in a later release, without changing its external
declaration.

Because there is no external sign that a function might actually return
an error, and because there is often not even a sign that a function is
being called (due to overloaded operators, implicit type conversions,
etc.), it is very hard to recognize all of the points in a function
where control flow may be interrupted due to an exception.  This renders
analysis of the function very problematic: under certain circumstances,
that operator+ may actually become a goto the end of the function!

Raoul:

|> Of course, that problem is solvable. But if
|> one wants to write exception-tolerant code, every line of every member
|> function must be scrutinized in order to prove that an object will be
|> destroyable under any condition. This is a lot of work. Moreover, even
|> if the code is carefully checked in its first incarnation, I suspect
|> that it won't be checked again in the maintenance phase.

James:

This is true.  But as an arguement against exceptions, it only holds in
so far as the alternative code will be checked for such cases.  I
believe that this will often be the case, because the alternative
control flow, taken in case of error, is (or should be) visible in the
code, whereas with exceptions, it is not.

Of course, the arguement against exceptions would be a lot stronger if
it were illegal to ignore a return value in C/C++ (as it is in Pascal,
for example).  That way, I could be sure that my return codes were not
being ignored (at least not accidentally).

At one customer site, we switched from exceptions to return codes.  But
for the return code, we use a class, which aborts the program if the
destructor is called before the return code is read.  We got a lot of
compaints from people used to the facility of the exception mechanism,
to the effect that the return codes were more work.  Of course they were
more work: you no longer got a default behavior (passing the error up
the chain), you actually had to think about error conditions!  Which, of
course, is the hard part, with or without exceptions.

(For what it is worth: the return code class was designed so that it
could be replaced by a typedef to int in the production code.  After
seeing the profiling results, we've not bothered.)