Exceptions vs. Error Codes

From: Shane Groff (shane_at_shaneandsusan.com)
Date: 10/10/04

  • Next message: Mike Wahler: "Re: Exceptions vs. Error Codes" 
    Date: 9 Oct 2004 17:35:17 -0700

    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?

  • Next message: Mike Wahler: "Re: Exceptions vs. Error Codes"

    Relevant Pages

    • Re: Exceptions vs. Error Codes
      ... > reading through threads on the topic), but I feel compelled to start ... > propagate the error is cleaner with exceptions. ... > than error codes, when in fact, they just don't see that it is just as ... > propagate the error, assuming they are following the pattern), some ...
      (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)