Exception Handling and Refactoring Question ...

[Master of C++]

Hi,

I am writing a simulation package in C++, and so far I've written about
8000 lines of code and have about 30 classes. I haven't used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.

Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I've come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I've read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.

Any suggestions, pointers or references will be greatly appreciated.

Thanks,
Vijay.

 

[Cy Edmunds]

Hi,

I am writing a simulation package in C++, and so far I've written about
8000 lines of code and have about 30 classes. I haven't used C++
exceptions so far (for various reasons). The only two "resources" I use
are memory and file I/O and whenever there is a memory allocation
failure or file I/O failure I just simply call a custom assert-type
function to check, print a error message and abort. This seems to be OK
for now (for the simulator base development), but when I start writing
a GUI to the simulator, I would require a more graceful way to handle
such exceptional situations.

Now, I am reading all the good things about C++ exception handling and
I am considering refactoring my code to use try-catch type exception
handling. Agreed, I should have thought about this before I started
writing a single line of code (my programming skills were much inferior
then) - But now that I've come this far, is it worth to do the
refactoring ?, or is it even possible without a complete redesign of
everything ? (because I've read in many places that exception handling
should be tightly coupled with the overall design). My other option is
to expand on the custom assert-type function to do more than just
display an error message and abort.

Any suggestions, pointers or references will be greatly appreciated.

Thanks,
Vijay.

I suggest you use ASSERT for errors which could only be caused by
programming errors and exceptions for errors which can be caused by
incorrect user input. The whole point of ASSERT is to help you with your
software testing. Since it drops out in the production code it is of no use
to the end user. Exception programming can be used to facilitate automatic
recovery (difficult but necessary in mission critical applications) or just
to make Good Error Messages -- "GEMs" (much easier).

You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running();
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.

Google for "programming by contract" to see some interesting ideas about how
to organize ASSERT programming.

HTH

 

[GB]

You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running();
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.

If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_error, not std::exception. Logic
errors of the type traditionally represented by assertions should derive
from std::logic_error (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and must perform parameter validation
without asserting.

Gregg

 

[GB]

You mention resources as if they were the only source of errors but any
useful software I ever saw is vulnerable to incorrect user input. Exceptions
can be a good way to deal with that problem, but considerable thought must
go into it. If your objective is just GEMs, you must ask yourself if your
end user is going to be able to figure out what he did wrong based on the
message you are giving him. I wish the programmers of some of the software I
use had thought about this a little more.

A console mode program which was just going for GEMs would look like this:

int main()
{
try {
start_running();
} catch (std::exception &e) {
std::cerr << e.what() << '\n';
}
}

Just derive all of your exception classes from std::exception and this is
it! In principle you don't need to write any other try blocks in the entire
program. Can't get much simpler than that.

If you are going to use the standard library exception classes the way
they were intended, then exception classes representing errors that
occur in the environment of the program, such as user errors, device I/O
errors, or resource errors, should be derived from std::runtime_error,
not std::exception. Exception classes representing logic errors of the
type traditionally represented by assertions should derive from
std::logic_error (if you want to use exceptions for this). I would
expect to find this sort of exception primarily in library code that is
intended to be widely reused and which must perform parameter validation
without asserting.

Gregg

 

[Cy Edmunds]

If you are going to use the standard library exception classes the way
they were intended, then errors that occur in the environment of the
program, such as user errors, device I/O errors, or resource errors,
should be derived from std::runtime_error, not std::exception.

You have confused the type being thrown with the type being caught. A
std::runtime_error *is* a std:exception -- all exception classes in
<stdexcept> are derived from std::exception. Hence the code I posted will
catch a std::runtime_error as well as any other std::exception.

However, this brings out an important point: if you write the catch phrase
as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphic behavior will be lost.

 

[Master of C++]

Thanks for your respones ! I am more clear than before about
exceptions. The general idea I am getting is that exceptions must be
used very judiciously (for truly exceptional situations) because they
can be easily misused. For other cases, I will go with with the good
ol' assert (as I am developing a whole package instead of a generic
library).

Thanks,
Vijay.

 

[GB]

You have confused the type being thrown with the type being caught. A
std::runtime_error *is* a std:exception -- all exception classes in
<stdexcept> are derived from std::exception. Hence the code I posted will
catch a std::runtime_error as well as any other std::exception.

I didn't confuse anything. You said "Just derive all of your exception
classes from std::exception". This is not in general good advice. I know
how catching by reference polymorphically works. In fact that is why
advising to derive from std::exception is not good advice.

However, this brings out an important point: if you write the catch phrase
as

catch (std::exception e)

the actual exception will be bit sliced down to a std::exception and the
polymorphic behavior will be lost.

Yes, that is true, but I didn't see anyone suggest catching that way. In
your previous post you were catching (std::exception&) which is almost
correct. In general, you should catch by const reference where possible.

Gregg

 

[Cy Edmunds]

I didn't confuse anything. You said "Just derive all of your exception
classes from std::exception". This is not in general good advice.

With the code I posted it wouldn't be correct to say that one must use
std::runtime_error -- any std::exception will work. And using or deriving
from std::runtime_error *is* deriving from std::exception, consistent with
my advice.

Looking at it another way, I did NOT say to NOT use std::runtime_error as
the actual exception to be thrown.

I know how catching by reference polymorphically works. In fact that is
why advising to derive from std::exception is not good advice.
Huh?


Yes, that is true, but I didn't see anyone suggest catching that way. In
your previous post you were catching (std::exception&) which is almost
correct. In general, you should catch by const reference where possible.

Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If the
catch phrase modifies it there can be no side effects. Hence the exception
belongs fully to the catch phrase which can do with as it pleases.

 

[GB]

With the code I posted it wouldn't be correct to say that one must use
std::runtime_error -- any std::exception will work. And using or deriving
from std::runtime_error *is* deriving from std::exception, consistent with
my advice.

Looking at it another way, I did NOT say to NOT use std::runtime_error as
the actual exception to be thrown.



Huh?

If you derive directly from std::exception, you have to either catch
your exception explictly, or catch all std::exception objects. You lose
the ability to catch your exception by catching only the
std::runtime_error subset.

Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If the
catch phrase modifies it there can be no side effects. Hence the exception
belongs fully to the catch phrase which can do with as it pleases.

No, it is not nonsense. If you don't catch by const reference, you will
fail to catch an exception that is a const object.

Gregg

 

[Cy Edmunds]

Nonsense. An exception object needn't be protected using const for the

No, it is not nonsense. If you don't catch by const reference, you will
fail to catch an exception that is a const object.

Gregg

Perhaps you could show a code example.

 

[GB]

Perhaps you could show a code example.

If I did, it would only demonstrate that I was wrong . Furthermore,
in an attempt to demonstrate how modifying an exception object in a
handler could cause a side effect, I learned of another misconception I
had. I thought the following code would print 2 instead of 1:

#include <iostream>

int e = 1;

int main()
{
try {
throw e;
} catch (int& e) {
++e;
}

std::cout << e << std::endl;
}

Both gcc 3.3 and Visual C++ 2005 beta print 1. Apparently a copy of the
exception object is made even if it is caught by reference. I did not
know this.

Gregg

 

[Alf P. Steinbach]

* Cy Edmunds -> Gregg B:

Looking at it another way, I did NOT say to NOT use std::runtime_error as
the actual exception to be thrown.

There is an issue here relating to "soft" versus "hard" exceptions; the
same issue reflected by the division of the exception class hierarchy in
some other languages such as Java and C#.

Catching std::exception in the 'main' function is OK. Catching std::exception
at lower levels might run the risk of catching e.g. std::bad_alloc (or worse).
Yes, mostly one does not care what exception is caught, mostly all exceptions
are in practice equal, but some are more equal than others...

However, as with many in things in C++ it's all about convention, and if there
isn't a reasonable convention being rigorously followed then what you do or
don't do doesn't matter: the non-conforming code makes all efforts
at sane exception handling moot (in my humble opinion).

Huh?

I gather he's referring to what I tried to sketch above: if even _one_ "soft"
exception class is derived directly from std::exception then that might
necessitate catching std::exception instead of std::runtime_error at low
levels, rendering a convention designed to let through "hard" exceptions
impotent.

Nonsense. An exception object needn't be protected using const for the
simple reason that the code which threw it has already been unwound. If the
catch phrase modifies it there can be no side effects. Hence the exception
belongs fully to the catch phrase which can do with as it pleases.

Well, for standard exceptions:

* Not using const indicates that there is an intent to modify.

On the other hand, some non-standard exceptions such as MFC exceptions must
be modified by the handler.