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.

--
PS (flame-guard): My id "Master of C++" has more to do with my favorite
album "Master of Puppets" than with my proficiency in C++.

[GB]

Cy Edmunds wrote:

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

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_er ror 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).

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

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_er ror at low
levels, rendering a convention designed to let through "hard" exceptions
impotent.

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.

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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?