TITLE: the costs of exception handling

(Newsgroups: comp.lang.c++.moderated, 6 Sep 97)


PERRAJU: Tolety Siva Perraju

> The following questions are repeatedly coming up,
> when we are trying to push for using exception mechanism
> as the standard method for error handling. Can any one please me
> address the following concerns:
> 
> 1. Exception handling increases code size and decreases performance.


CLAMAGE: Steve Clamage <stephen.clamage_nospam@Eng.Sun.COM>

Compared to what? Compared to ignoring errors, yes.

Compared to writing the extra code to pass around error status, 
exception code should be more compact, run faster (in the absence
of the exceptional conditions), and be easier to understand and 
maintain.

Of course, a particular compiler might have a poor implementation of 
exceptions. But many compilers impose no run-time cost (except for
static tables) when exceptions do not occur. Ordinary error checking 
imposes a run-time penalty even when errors do not occur.

Exception handling might be slower than ordinary error-handling
code when the exceptions do occur. OTOH, the exception mechanism
is doing work for you that you otherwise would have to write
your own code to do.


PERRAJU:

> 2. Exception handling is brittle.

CLAMAGE:

Designing classes that are safe in the presence of arbitrary
exceptions is very difficult. It isn't so much the exception
handling that is brittle, but that things can be left in an
inconsistent state when an exception causes the main-line code
to be bypassed. When exceptions can occur in arbitrary code,
you have to allow for the possibility that any function
you call might not return (except for stack unwinding).


PERRAJU:

> 3. All compilers do not handle exception handling uniformly, so
>    the code which works on one platform can break on another
>    platform. ...

CLAMAGE:

Certainly there are variations in compilers' correctness
and efficiency in dealing with exception code, just as with
any other part of C++. I would say the variation is much
greater for templates than for exceptions, however. If you
are required to use compilers for deliverable code now
whose exception implementation is suspect, you should avoid
using exceptions until such time as those compilers are improved.