[LC++]Exceptions vs. Errors

Paul M Foster paulf at quillandmouse.com
Thu Apr 18 13:03:05 UTC 2002


I've searched through comp.lang.os.c++, looking for comments on the
exceptions vs. errors debate, and I've watched comments on this list as
well. There seems to be no concensus; some people feel that exceptions
are the way to go for almost everything, others feel that exceptions are
only really good for things that ought to gracefully terminate a
program.

One remark I've seen in favor of exceptions is that programmers often
ignore error values returned by routines. However, it has occurred to me
that exceptions have the opposite (and possibly disasterous) effect.
They _force_ a programmer to deal with them. Except that this isn't
exactly true. If a programmer fails to catch a throw, his program could
end up terminating for some trivial reason.

Example (and I've seen this exact thing): a date class throws an
exception if a user enters year 0. The rationale is that there was no
year 0. However, if the programmer using this class fails to catch the
exception, his program may terminate because of this. This could
conceivably get all the way through alpha and beta testing.

One other thing I've seldom seen remarked is that, unlike testing for
return values, which should be done after each function call, exceptions
allow one to put a lot of actions in a try block, and then catch them
all at the end.

I'm building an extensive set of classes for a project, and having to
deal with this question of exceptions versus errors. The tentative
guideline I'm using is that if a failed function (or sequence of
functions) would result in an unfixable condition, it gets an exception.
For example, if an object must connect with the database daemon and
can't, then the program can't very well continue. Exception. If the
application has to create a table in a database, but the database daemon
won't allow it (SQL syntax error, duplicate of an existing table, etc.),
then we can't go on. Exception. 

Does this sound reasonable?

Paul





More information about the tuxCPProgramming mailing list