Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1699

Re: Error codes vs. exceptions

Cross-posted to 2 groups.

Show all headers | View raw

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>


As shown by the various exception messages there are (at least) 4 ways 
that "strtol" can fail.

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 
(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. ;-)


Cheers & hth.,

- Alf

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-28 21:15 -0700
  Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 00:10 -0500
    Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-28 22:41 -0700
      Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 01:34 -0500
    Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-29 07:16 -0700
      Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-29 09:45 -0500
  Re: Error codes vs. exceptions Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-05-29 09:08 +0200
    Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-31 13:52 -0700
      Re: Error codes vs. exceptions Ian Collins <ian-news@hotmail.com> - 2012-06-01 09:08 +1200
        Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-05-31 22:32 -0700
  Re: Error codes vs. exceptions "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-05-29 09:37 +0200
  Re: Error codes vs. exceptions "io_x" <a@b.c.invalid> - 2012-05-29 10:00 +0200
  Re: Error codes vs. exceptions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-05-29 12:24 +0000
  Re: Error codes vs. exceptions Nobody <nobody@nowhere.com> - 2012-05-30 15:23 +0100
    Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-30 09:40 -0500
      Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-30 08:04 -0700
        Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-05-30 12:01 -0500
  Re: Error codes vs. exceptions Jeff Flinn <TriumphSprint2000@hotmail.com> - 2012-05-30 14:18 -0400
    Re: Error codes vs. exceptions Patricia Shanahan <pats@acm.org> - 2012-05-30 13:00 -0700
    Re: Error codes vs. exceptions Adam Skutt <askutt@gmail.com> - 2012-05-30 21:25 -0700
  Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-05-30 22:44 -0400
    Re: Error codes vs. exceptions Nobody <nobody@nowhere.com> - 2012-05-31 05:04 +0100
    Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-06-01 21:44 -0400
  Re: Error codes vs. exceptions "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2012-06-02 08:39 +0200
    Re: Error codes vs. exceptions BGB <cr88192@hotmail.com> - 2012-06-02 16:31 -0500
    Re: Error codes vs. exceptions mike3 <mike4ty4@yahoo.com> - 2012-06-02 15:49 -0700
      Re: Error codes vs. exceptions Ian Collins <ian-news@hotmail.com> - 2012-06-03 11:17 +1200
      Re: Error codes vs. exceptions Rui Maciel <rui.maciel@gmail.com> - 2012-06-03 16:38 +0100
    Re: Error codes vs. exceptions Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-06-03 20:26 -0400
  Re: Error codes vs. exceptions gremnebulin <peterdjones@yahoo.com> - 2012-06-20 12:05 -0700

csiph-web