Re: Exceptions vs. Error Codes

From: Alf P. Steinbach (alfps_at_start.no)
Date: 10/10/04 

Date: Sun, 10 Oct 2004 01:59:15 GMT

* Shane Groff:
> 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

Constructors can produce error codes. A constructor can take a reference
or pointer argument, or it can store an error code somewhere else. One
main reason why that is not a _good idea_ is that the built-in mechanism
for cleaning up when an objected is allocated dynamically and the
constructor fails, requires an exception from the constructor, and that
similar techniques implemented by oneself have the same requirement; without
such automated cleanup there is a live but invalid object around.

Another main reason is that the approach is not general: additional arguments
cannot be tacked on to a copy constructor or, as you write, an operator, so
these would have to store their error codes in some accessible place.

The "live but invalid" argument is also the main argument for not using
two-phase construction (except when encapsulated by an object factory).

> 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.

Yup.

> 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.

Macros are evil.

An alternative is to make the error code an object that requires a check()
or value() or succeeded() call or something in order not to throw an
exception.

Some folks have advocated that approach e.g. because it makes the code more
explicit; one main drawback is that all code everywhere must then check every
function call for possible error, giving C-style impenetrable code, and
another main drawback is that exceptions are needed for constructors and
such anyway, lest one wind up with "live but invalid" objects... 

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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)
  • 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: exception and global variable
    ... exceptions or using catchto catch all exceptions. ... Let the guy do some reading and use help of the nice folks ... But I do not think it is true, because we can add function try block to its constructor, and catch appropriate types ... EggHeadCafe - .NET Developer Portal of Choice ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Design Question/Constructor Exceptions?
    ... job of a constructor is to prepare a class to be ready for use, ... Constructors certainly may throw exceptions, ... programmers) that's part of your HoursMinutesSeconds API. ... the form of throwing an IllegalArgumentException: ...
    (comp.lang.java.programmer)
  • Re: Catching exceptions thrown from base class constructors?
    ... Although CPP allows you to throw exceptions from the constructor, ... setter from the constructor and let the setter throw the exception if so ... If the base class one throws the derived class ctor ...
    (alt.comp.lang.learn.c-cpp)