🚀 go-pugleaf

In article <b53899e6.0110171315.5036e57c@posting.google.com>,
elgoog@strangelight.com (Jason Lamport) wrote:

> I noticed some interesting behaviour when playing with a little test
> program:
> ________________test.cpp__________
> class Error {
>         public:
>                 Error();
>                 virtual ~Error();
> };
> 
> Error::Error() {
>         printf( "Instantiating Error object %X\n", (long) this );
> }
> 
> Error::~Error() {
>         printf( "Destructing Error object %X\n", (long) this );
> }
> 
> void funcA();
> void funcB();
> 
> void funcA() {
>         printf( "Entering funcA()\n");
>         try {
>                 printf( "Trying funcB()\n");
>                 funcB();
>         } catch (Error& e2) {
>                 printf( "Rethrowing object %X\n", (long) &e2 );
>                 throw( e2 );
>         }
> }
> 
> void funcB() {
>         printf( "Throwing Error object....\n");
>         throw( Error() );
> }
> 
> int main() {
>         printf( "Entering main()\n");
>         try {
>                 printf( "Trying funcA()\n");
>                 funcA();
>         } catch (Error& e1) {
>                 printf( "Caught Error object %X\n", (long) &e1 );
>         }
>         printf( "leaving main()\n");
>         return 0;
> }
> ___________end____________
> 
[snip]
> 
> The output was also interesting:
> 
> _____________output of test.cpp____________
> Entering main()
> Trying funcA()
> Entering funcA()
> Trying funcB()
> Throwing Error object....
> Instantiating Error object 598CC58
> Rethrowing object 598CC58
> Destructing Error object 598CC58
> Caught Error object 598CC74
> Destructing Error object 598CC74
> leaving main()
> ________________end________________
> 
> It seems that re-throwing the object copies the object to another
> memory location (further up the stack?), destructs the old copy, but
> does *not* call the new copy's constructor. (Notice that the output
> indicates two destructor calls but only one constructor call.) This
> could cause some very hard-to-find bugs if one were relying on the
> usual assumption that constructor calls and destructor calls always
> occur in matched pairs.

The program is doing exactly what you told it to do:

a) You didn't rethrow the exception. Instead, you threw a copy of it.
To rethrow the same exception, say

    throw;              // rethrow e2

instead of

    throw (e2);         // throw copy of e2

b) The copy was constructed using the copy constructor, not the default
constructor. You supplied your own printf-calling default constructor,
but you neglected to supply a copy constructor, so the compiler
generated one for you (and didn't bother to put a printf in it). If you
want to see copies taking place, you need to also supply a copy
constructor, something like:

    Error::Error (const Error& rhs) {
        printf( "Copying Error object %X into %X\n",
                (long) &rhs, (long) this );
    }

Also, note that printf is not exception-safe. That doesn't matter in
this program, but I mention it in passing since this thread is about
what's safe to do from an exception handler.

-Ron Hunsinger