By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,494 Members | 1,136 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,494 IT Pros & Developers. It's quick & easy.

Moving from Return Codes to Exception Handling

P: n/a
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

Jul 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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.

Jul 23 '05 #2

P: n/a
On 2005-07-12, Josh Mcfarlane <da*****@gmail.com> 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/
Jul 23 '05 #3

P: n/a
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::out_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
Jul 23 '05 #4

P: n/a
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
Jul 23 '05 #5

P: n/a
> 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

Jul 23 '05 #6

P: n/a
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.

Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.