Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Exceptions vs. Error Codes

Reply
Thread Tools

Exceptions vs. Error Codes

 
 
Shane Groff
Guest
Posts: n/a
 
      10-10-2004
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?
 
Reply With Quote
 
 
 
 
Mike Wahler
Guest
Posts: n/a
 
      10-10-2004

"Shane Groff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> 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


 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      10-10-2004
* 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?
 
Reply With Quote
 
Shane Groff
Guest
Posts: n/a
 
      10-10-2004
"Mike Wahler" <(E-Mail Removed)> wrote in message news:<z90ad.758$(E-Mail Removed) nk.net>...
> "Shane Groff" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) om...
> > 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.
> >
> >
> > 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


I'm not sure I understand. If I have local objects within the
function, they will be destroyed when the function exists whether the
exit is through a normal return, or an exception. If every function
is written along the pattern above, then each function jumps to the
return and passes the error code back up the chain, and local objects
are destroyed when the function returns.
 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      10-10-2004

"Shane Groff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
>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).


I think your reasoning is spot on. I've seem many examples where code
appears to be checking for errors because there are loads of if statements
checking return values (often this is the bulk of the code!) but when you
actually test it doesn't work because somewhere in the chain of function
calls a return value check was missed, or because the code has been hacked
around the cleanup after detecting an error doesn't work correctly.

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


In C++ you are not allowed to jump over a declaration. So this would force
you into C style code where all the declarations are at the start of a
block.

john


 
Reply With Quote
 
Michael Kurz
Guest
Posts: n/a
 
      10-10-2004

"Shane Groff" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) om...
> "Mike Wahler" <(E-Mail Removed)> wrote in message

news:<z90ad.758$(E-Mail Removed) nk.net>...
> > "Shane Groff" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed) om...
> > > 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.
> > >
> > >
> > > 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.


>
> I'm not sure I understand. If I have local objects within the
> function, they will be destroyed when the function exists whether the
> exit is through a normal return, or an exception. If every function
> is written along the pattern above, then each function jumps to the
> return and passes the error code back up the chain, and local objects
> are destroyed when the function returns.


You are right. The stackunwinding is only needed when you throw an exception
somewhere several levels deep in a callstack and the exception hanling need
to unwind all these calls in progress. In your sample this is not a problem.
I think goto would not allow this anyway.


Regards
Michael


 
Reply With Quote
 
Michael Kurz
Guest
Posts: n/a
 
      10-10-2004

"Shane Groff" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed) om...
>
> 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?


I have seen these kind of error handling many times in code, but somehow I
never liked the necessary goto statement.
So I never used it myself.

When I have to decide if I should use exception handling or error codes I
have mostly the following things in mind:
- Error codes are self documenting whereas exceptions are not.
- Exceptions are slower so if its within performance critical code I dont
want to open a try/catch block all the time.
- Exception lead to a cleaner caller code.
- C++ constructs throw exceptions themselfes (new) so If not using
exceptions as error communication these should be converted to error codes
or avoided (hard to achieve), which is quite an effort and a possible
performance problem again .
- Make code (caller) exception safe requires some knowledge. After reading
Herb Sutters "Exceptional C++" I wondered why my programs ever worked
properly


IMHO at the end its a mixture of the requirements your code has to foolfill
and a bit of personal taste.



Best Regards
Michael






 
Reply With Quote
 
Michael Kurz
Guest
Posts: n/a
 
      10-10-2004

"Michael Kurz" <(E-Mail Removed)> schrieb im Newsbeitrag
news:416902db$(E-Mail Removed)...
>
> IMHO at the end its a mixture of the requirements your code has to

foolfill

sorry, meant fulfill of course.




 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-10-2004

"Shane Groff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> "Mike Wahler" <(E-Mail Removed)> wrote in message news:<z90ad.758
> > One obvious disadvantage of your 'error code' solution is that
> > it doesn't implement 'stack unwinding' i.e. automatic destruction,
> > whereas exceptions do.
> >
> > -Mike

>
> I'm not sure I understand. If I have local objects within the
> function, they will be destroyed when the function exists whether the
> exit is through a normal return, or an exception. If every function
> is written along the pattern above, then each function jumps to the
> return and passes the error code back up the chain, and local objects
> are destroyed when the function returns.


Right. But with exceptions, you don't need to write anything.
Just throw the exception and it 'just works'.

-Mike


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Error codes vs. exceptions mike3 C++ 135 06-20-2012 07:05 PM
How to use file I/o codes with form and controls codes Allen ASP .Net 1 12-03-2007 12:04 AM
Should I use exceptions instead of error codes? mike3 C++ 14 11-17-2007 10:04 PM
Virtual Key Codes, Scan Codes and ASCII Codes in C gj_williams2000@yahoo.co.uk C Programming 2 08-20-2005 11:04 AM
RegEx replace of html codes to ascii codes Greg -- ASP .Net 4 08-09-2005 07:27 PM



Advertisments