Re: Error codes vs. exceptions
Alf P. Steinbach wrote:
On 29.05.2012 06:15, mike3 wrote:
Hi.
I've heard about this [Error codes vs. exceptions], and wonder when is it
right to use codes, and when to use exceptions for reporting errors?
Use whatever's more clear and practical in any given case.
And note that "codes" include the case of zero information about what failed,
where there's only one success indicating code (like boolean "true") and one
failure indicating code (like boolean "false")...
Also note that there are many other techniques for handling failures that occur
in a function f:
* let f return a possibly empty result
e.g. check out Barton/Nackman "Fallible" and Boost "optional"
* let f call an error handling routine, that's possibly configurable
a great many libraries do this
* let f terminate the program
a bit harsh, but e.g. a JPEG library used by ImageMagick did this
* let f involve the user and try to fix the problem
this was used in Windows for missing removable media, missing
DLLs and so on, with a box that like DOS did earlier said "abort,
ignore, retry" (or the like)
* let f simply have undefined behavior
may sound pretty stupid but is used by e.g. the C++ standard library
for functions where failures only are caused by failed preconditions
Regardless, you have the option of letting f log the incident, or not.
But generally, e.g. when I'm going to call a C library function or Windows API
function that (as they typically do) has some ad hoc fault indication + some
error code scheme, then I usually wrap it in a function or expression that
throws a C++ exception. That's generally more convenient even for local handling
of the failure. And one main reason is that it encapsulates and gets rid of all
the myriad ad hoc schemes for checking whether the function failed and for
responding to it -- it's a standardization and simplification.
As an example,
<code>
// `errno` may be an expression macro, so it cannot (portably) be qualified with
"::".
int stdErrno() { return errno; }
void clearStdErrno() { errno = 0; }
bool hopefully( bool const condition ) { return condition; }
bool throwX( string const& s ) { throw runtime_error( s ); }
long longFrom(
char const spec[],
int const radix = 0,
bool const acceptTrailingChars = false
)
{
char* pEndOfScan = 0; // The unsafe type is required by `strtol`.
clearStdErrno();
long const result = strtol( spec, &pEndOfScan, radix );
string const failureDescription = 0?string()
: pEndOfScan == spec?
"longFrom failed: the number spec was not accepted by strtol()."
: stdErrno() == ERANGE?
"longFrom failed: the specified number value is too large for strtol()."
: stdErrno() != 0?
S() << "longFrom failed: strtol() failed, errno = " << stdErrno() << "."
: *pEndOfScan != '\0' && !acceptTrailingChars?
"longFrom failed: extraneous character(s) after valid number spec."
:
"";
hopefully( failureDescription.length() == 0 )
|| throwX( failureDescription );
return result;
}
</code>
Thanks for the great real-world example, Alf!
I am largely agree to your post but, as I often use strto.. family of functions,
I have few comments:
As shown by the various exception messages there are (at least) 4 ways that
"strtol" can fail.
Please note that one of them requires your application-specific flag,
`acceptTrailingChars' to be detected. It is an often case that an application
requires this flag (sometimes, the result of strtol shall be in a range (even if
as broad as range of int because there is no equivalent strtoi standard
function). This supports my earlier point that often some application-level
tweaking has to be done directly after calling a 3rd-party library function. In
your case if strtol were a C++ function and threw exception where it now sets
errno, you would still need to write some error-processing code right after
calling the function for this condition.
I would speculate that in many programs using the "strtol" function directly,
not all failure paths are checked -- but the wrapper replaces the sequence of
four ad hoc checks with simple standard C++ exception handling.Of course, with
a C++11 conforming compiler there's little need to call "strtol" because in
C++11 iostreams do that for you
As a frequent user of strtoXxx and streams I tend to disagree. To even
approximately match the performance of my current code, using streams would make
me implement my own streambuf over given fixed buffer (which I really do not
need as I am fine with the more mundane approach of parsing from specific
position in my directly-manipulated read buffer (which is essentially a RAII
holder over character buffer, that is a much simpler class than streambuf)).
I thought of using strings as buffers and parsing istringstream but rejected the
idea. The direct manipulations with the contents of std::string-underlying
stringbuffer are UB and using string modifiers would trigger contents copy on
COW strings (for non-COW strings I would pay for the contents copy even earlier,
when I construct stringbuffer instance).
(C++03 instead used the "scanf" family, with
possible Undefined Behavior). But I think it illustrates the case for wrapping
in C++.
So, C = preference for codes, error handlers functions etc., and C++ =
preference for exceptions. But in some cases, as with e.g. calls across binary
module boundaries, you can't assume C++ exception support. Then you have to
design for the code to be callable as C, i.e. no exceptions.
All that said, I'm primarily responding because I'm really curious about where
this great need for MECHANICAL RULES comes from?
If programming could be reduced to mechanical rules, if that was a good idea,
then, u know, it could be automated, and then you would not have this problem of
finding the rules because you wouldn't be programming: it would be done by
machine... So, instead of seeking mechanical rules to be applied mindlessly, I
suggest seeking up concrete EXAMPLES of failure handling.
Then apply
INTELLIGENCE and understanding of concrete situations that you face, and just
strive to Keep Things Simple. ;-)
Fully agree with all of the above.
Cheers & hth.,
- Alf
-Pavel