[LC++]Exceptions vs. Errors

[Jack Lloyd]

I think if it's something that's easy to test for in the calling code, it's
better to use errors instead of exceptions. For example, if you create an
ifstream for a file that doesn't exists, you can just put if(!file) {
errorhandling; }. Especially for pointers; it's just so easy to check for a
null pointer (programmers, at least C/C++ ones, will do that pretty much as
a reflex if there is a possiblity that a function might return null), and
often enough the local code _is_ able to do something about it. I find the
try/throw/catch syntax ugly enough that I don't like using it unless I have
to.

Signalling more general success or failure (for example, was some
operation, which the program can't directly go and check on, executed to
completion?) is probably more an exception thing. An example would be
something like a database or network failure. That's not to say the program
should terminate (though of course that varies from app to app). But
something like that seems better handled in the upper levels of the code.

As always, YMMV. -J

On Wed, 17 Apr 2002, Paul M Foster wrote:

> 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
>
>
> _______________________________________________
> This is the Linux C++ Programming List
> : http://lists.linux.org.au/listinfo/tuxcpprogramming List
>