Moving from Return Codes to Exception Handling

Discussion in 'C++' started by Josh Mcfarlane, Jul 12, 2005.

  1. I keep trying to get myself out of the return-code mindset, but it
    doesn't seem to work. They are suppose to get rid of if-then statements
    of return codes, but you still have to do an if statement once the code
    leaves your control (3rd party libraries, OS functions, etc) to throw
    an exception?

    Does anyone have any good suggestions on a book or website that deals
    with exception handling that could help turn this poor mind off of
    return codes? =)

    Thanks,
    Josh McFarlane
    Josh Mcfarlane, Jul 12, 2005
    #1
    1. Advertising

  2. Josh Mcfarlane

    Bart Guest

    Josh Mcfarlane wrote:
    > I keep trying to get myself out of the return-code mindset, but it
    > doesn't seem to work. They are suppose to get rid of if-then statements
    > of return codes, but you still have to do an if statement once the code
    > leaves your control (3rd party libraries, OS functions, etc) to throw
    > an exception?


    Yes, if you want to raise an exception for every 3rd party library
    call, but you don't have to. The point of exceptions is not to get rid
    of error handling altogether, just make it easier/more natural to pass
    information about the error from the point where the error occurs to
    the point where the error recovery occurs. In other words, you don't
    need to do error checks at all levels in the caller tree and you don't
    have to use special error reporting functions or globals such as
    'errno'. All the information about the error is contained in an
    exception object.

    You also have the added advantage that you don't need to write code
    like this:

    if(func1())
    {
    if(!func2())
    undofunc1();
    else
    {
    if(func3())
    {
    undofunc2();
    undofunc1();
    }
    else
    ...
    }
    }

    Or use goto statements to do the above. Each of the above operations
    can be done in a class constructor and undone in a class destructor.
    You would only have to to write:

    Operation1 op1(/*params here*/);
    Operation2 op2(/*params here*/);
    Operation3 op3(/*params here*/);

    Much cleaner isn't it?

    > Does anyone have any good suggestions on a book or website that deals
    > with exception handling that could help turn this poor mind off of
    > return codes? =)


    "Exceptional C++", by Herb Sutter.


    Bart.
    Bart, Jul 12, 2005
    #2
    1. Advertising

  3. On 2005-07-12, Josh Mcfarlane <> wrote:
    > I keep trying to get myself out of the return-code mindset, but it
    > doesn't seem to work. They are suppose to get rid of if-then statements
    > of return codes, but you still have to do an if statement once the code
    > leaves your control (3rd party libraries, OS functions, etc) to throw
    > an exception?


    One way is a layer of indirection -- just wrap the functions.

    This is not always a satisfactory solution, but there are instances where it's
    exactly what you need.

    Another way you could do this is to wrap the exception constructor:

    void FileErrorCheck (FILE* f)
    {
    if (f == NULL) { throw FileError ( errno ); }
    }

    ....

    FILE* f;
    FileErrorCheck( f = fopen(filename,"r"));

    Of course you still have to type some extra code per call, but the bottom line
    is that there's got to be extra code somewhere -- either in the calling function
    or the called function (via a wrapper)

    Code similar to the above example is sometimes used by C programmers -- they'll
    have a macro that does a bunch of things to reduce the code overhead associated
    with this sort of checking.

    Cheers,
    --
    Donovan Rebbechi
    http://pegasus.rutgers.edu/~elflord/
    Donovan Rebbechi, Jul 12, 2005
    #3
  4. Josh Mcfarlane wrote:

    > I keep trying to get myself out of the return-code mindset, but it
    > doesn't seem to work. They are suppose to get rid of if-then statements
    > of return codes, but you still have to do an if statement once the code
    > leaves your control (3rd party libraries, OS functions, etc) to throw
    > an exception?
    >
    > Does anyone have any good suggestions on a book or website that deals
    > with exception handling that could help turn this poor mind off of
    > return codes? =)
    >
    > Thanks,
    > Josh McFarlane


    Like, get with the '90s dude! ;)

    Exception handling in C++ has been one of the hardest adjustments for me to
    make while coming from Java to C++. It's hard to use exceptions well in
    C++; to a large extent because the other guy doesn't do it well,
    consistently, or at all. In addition, there is much more flexibility (than
    in Java) in what is actually thrown, how it is caught (by reference, or by
    value), how it is (or can be) processed, and in using exception
    specifications.

    As for a source on exception handling, there is Stroustrup's tome,
    TC++PL(SE). It is exhaustive in its discussion of exception handling.
    That's not exactly the same as saying it is helpful.

    For me, one consistent difficulty is to understand what the various types of
    std::exception derivatives really mean. For instance. what are the
    differences between std::eek:ut_of_range, std::range_error and
    std::length_error? Sure, I can look it up when I need to know, but I
    rarely remember the subtleties when I want to use one of these. That makes
    using them time consuming.

    --
    If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true.-Bertrand Russell
    Steven T. Hatton, Jul 12, 2005
    #4
  5. Josh Mcfarlane wrote:

    > I keep trying to get myself out of the return-code mindset, but it
    > doesn't seem to work. They are suppose to get rid of if-then statements
    > of return codes, but you still have to do an if statement once the code
    > leaves your control (3rd party libraries, OS functions, etc) to throw
    > an exception?


    Just write a wrapper function with the if-throw, and use the wrapper instead
    or the original function.

    --
    Salu2
    =?ISO-8859-15?Q?Juli=E1n?= Albo, Jul 12, 2005
    #5
  6. > I keep trying to get myself out of the return-code mindset, but it
    > doesn't seem to work. They are suppose to get rid of if-then statements
    > of return codes, but you still have to do an if statement once the code
    > leaves your control (3rd party libraries, OS functions, etc) to throw
    > an exception?


    You always have to adapt to old code or 3rd party libraries so that's
    nothing new. Exceptions were not meant to "get rid of if-then
    statements of return codes", but to signal to the caller that something
    happened and recovery is impossible. They are many cases where error
    codes just don't make sense, such as when every possible return value
    is legal or in a constructor. Error codes are still very useful.

    > Does anyone have any good suggestions on a book or website that deals
    > with exception handling that could help turn this poor mind off of
    > return codes? =)


    Concerning return codes and exceptions no, but Herb Sutter wrote two
    good books about (among other things) exception handling ( [More]
    Exceptional C++).

    Make sure you don't go crazy with exceptions. Use them when 1) they
    make the code clearer; 2) you cannot use return values; 3) few other
    circumstances.

    Jonathan
    Jonathan Mcdougall, Jul 12, 2005
    #6
  7. Josh Mcfarlane

    Bart Guest

    Donovan Rebbechi wrote:
    > void FileErrorCheck (FILE* f)
    > {
    > if (f == NULL) { throw FileError ( errno ); }
    > }
    >
    > ...
    >
    > FILE* f;
    > FileErrorCheck( f = fopen(filename,"r"));


    That doesn't work if you have multiple operations and you need to undo
    the effects of previous operations before throwing. To do that a better
    way is to wrap the calls in classes as in the example I have given.


    Bart.
    Bart, Jul 13, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    2,794
    Malcolm
    Aug 20, 2005
  2. Steve Simmons

    handling return codes from CTYPES

    Steve Simmons, Jan 21, 2013, in forum: Python
    Replies:
    2
    Views:
    95
    Chris Angelico
    Jan 22, 2013
  3. Mike C. Fletcher

    Re: handling return codes from CTYPES

    Mike C. Fletcher, Jan 21, 2013, in forum: Python
    Replies:
    0
    Views:
    116
    Mike C. Fletcher
    Jan 21, 2013
  4. Steve Simmons

    Re: handling return codes from CTYPES

    Steve Simmons, Jan 21, 2013, in forum: Python
    Replies:
    0
    Views:
    101
    Steve Simmons
    Jan 21, 2013
  5. MRAB
    Replies:
    0
    Views:
    107
Loading...

Share This Page