Re: Exceptions vs. Error Codes

From: Mike Wahler (mkwahler_at_mkwahler.net)
Date: 10/10/04 

Date: Sun, 10 Oct 2004 01:22:39 GMT

"Shane Groff" <shane@shaneandsusan.com> wrote in message
news:78817520.0410091635.68ee30d1@posting.google.com...
> I know this is a recurring discussion (I've spent the last 3 days
> reading through threads on the topic), but I feel compelled to start
> it up again.
>
> After reading through the existing threads, I find myself convinced
> that exceptions are a better mechanism, for example because
> constructors and operators can't return errors, and code that doesn't
> need to handle/translate/recover in the face of errors, but can just
> propagate the error is cleaner with exceptions.
>
> However, those reasons are often not compelling enough to convince
> people who don't like exceptions (usually in my experience because
> they incorrectly think that exceptions are more 'dangerous' somehow
> than error codes, when in fact, they just don't see that it is just as
> dangerous to ignore an error code as it is to not handle an exception
> when it should be).
>
> Consider this idiom when using error codes:
>
> ErrorCode EcFoo()
> {
> ErrorCode ec;
> Check(EcBar());
> Check(EcBletch());
> ...
> Exit:
> return (ec);
> }
>
> Here, Check is a macro that checks the return code and jumps to Exit
> if an error occurs.
>
> Using this pattern, we avoid the appearance of a slew of if/then
> statments (although they are there, of course, just hidden by the
> preprocessor).
>
> This makes the code almost as straightforward as the exception case,
> and doesn't introduce much overhead (space or time), since it is
> basically just adding a check for 0 to each call.
>
> This addresses some of the problems I've seen leveled against error
> codes. Although it seems to me that we're just writing what amounts to
> our own equivalent to exceptions here (for example, functions that
> don't handle the error don't need to do any 'additional' work to
> propagate the error, assuming they are following the pattern), some
> people are more comfortable with this because they know that returning
> and checking for error codes is always fairly inexpensive, while
> throwing an exception can be expensive.
>
> Any specific thoughts on the idiom, or compelling arguments to offer
> for the use of exceptions to the reluctant?

One obvious disadvantage of your 'error code' solution is that
it doesn't implement 'stack unwinding' i.e. automatic destruction,
whereas exceptions do.

-Mike

Relevant Pages

  • Exceptions vs. Error Codes
    ... After reading through the existing threads, ... propagate the error is cleaner with exceptions. ... Consider this idiom when using error codes: ... Using this pattern, we avoid the appearance of a slew of if/then ...
    (comp.lang.cpp)
  • Re: Exceptions vs. Error Codes
    ... > reading through threads on the topic), but I feel compelled to start ... Constructors can produce error codes. ... A constructor can take a reference ... > propagate the error is cleaner with exceptions. ...
    (comp.lang.cpp)
  • Re: Evaluating Exceptions, Try Except and Try Finally
    ... Delphi has used exceptions since the beginning. ... > way that it returns success/failure and possibly error codes. ... Error_Is_Joined surely can't be the same as the handling of ...
    (alt.comp.lang.borland-delphi)
  • Re: Evaluating Exceptions, Try Except and Try Finally
    ... Raising Exceptions is not ment as a means of returning success/failure or ... way that it returns success/failure and possibly error codes. ... IF THEN ELSE statements allow a programmer to handle situation right there ...
    (alt.comp.lang.borland-delphi)