Moving from Return Codes to Exception Handling

[Josh Mcfarlane]

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

 

[Bart]

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.

 

[Donovan Rebbechi]

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,

 

[Steven T. Hatton]

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

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

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.

 

[Jonathan Mcdougall]

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

 

[Bart]

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.