S
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, 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?
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?