2

We have an custom error class that is used whenever we throw an exception:

class AFX_CLASS_EXPORT CCLAError : public CObject

It has the following copy constructor defined:

CCLAError(const CCLAError& src) { AssignCopy(&src); } // (AssignCopy is a custom function)

It was originally written and compiled / linked with MSVC6 (Visual Studio 2003). I am in the process of doing necessary changes to get it to compile and link against MSVC8+ (VS 2008+)

When the msvc8 linker is invoked, i get the following error:

LNK2001: unresolved external symbol "private: __thiscall CObject::CObject(class CObject const &)" (??0CObject@@AAE@ABV0@@Z)

I understand what the error is telling me: no copy constructor is defined for some child of CObject, so its going all the way up the inheritance tree until it hits CObject, which as no copy constructor defined.

I first saw the error when compiling the library that defines and first throws a CCLAError, which is why I am proceeding as if that is the cause.

I was able to resolve the error by changing

throw CCLAError( ... )

to 

throw new CCLAError( ... )

and 

catch(CCLAError& e)
{
   throw e;
}

to 

catch(CCLAError& e)
{
   throw;
}

However, I do not understand why re-throwing a caught exception would invoke the copy constructor. Am I missing somethnig completely obvious? Subsequently, why would removing the variable holding a reference to a caught exception cause the copy constructor to not be invoked?

johnluetke
  • 3,393
  • 1
  • 20
  • 25
  • 1
    You don't need to, nor should you be, using `new` when throwing the original exception. But you definately need to change `throw e` to just `throw` to re-throw an existing exception without creating a new instance of it. – Remy Lebeau Jun 01 '12 at 18:32

6 Answers6

11

The type of the object thrown must be copyable because the throw expression may make a copy of its argument (the copy may be elided or in C++11 a move may take place instead, but the copy constructor must still be accessible and callable).

Rethrowing the exception using throw; will not create any copies. Throwing the caught exception object using throw e; will cause a copy of e to be made. This is not the same as rethrowing the exception.

Your "updated" code does not work as you expect. catch (CCLAError&) will not catch an exception of type CCLAError*, which is the type of the exception thrown by throw new CCLAError(...);. You would need to catch CCLAError*. Do not do this, though. Throw exceptions by value and catch by reference. All exception types should be copyable.

James McNellis
  • 348,265
  • 75
  • 913
  • 977
5

However, I do not understand why re-throwing a caught exception would invoke the copy constructor.

It doesn't, but re-throwing the thrown exception is done with throw;. When you do throw e; you are requesting to throw a copy of the caught exception.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • Makes sense. Since `throw e` was valid in MSVC6, and now is not in MSVC8 (as demonstrated by `throw` being valid), do they both achieve the same result? Or is the old code leaking memory? – johnluetke Jun 01 '12 at 18:33
  • 1
    @johnluetke: Whenever you `throw` a pointer then its leaked (trying to _delete_ it is troublesome). And `throw e` could result in slicing if you catch by value, that's why `throw;` is there. – K-ballo Jun 01 '12 at 18:35
3

Several points:

1st of all don't call throw new foo() use throw foo

2nd when your write:

catch(foo const &e) {
   throw e;
}

You actually create a new exception, and if for example the exception that was thrown is subclass of foo they my calling throw e you would loose this information and actually use a copy constructor to generate foo from e - whatever it was.

Now when you call

catch(foo const &e) {
   throw;
}

You don't create a new exception but rather propagate the same exception.

So: never use throw e; to propagate the exception forward, use throw;

Artyom
  • 31,019
  • 21
  • 127
  • 215
1

When you throw an exception, the object you're throwing generally resides on the stack. The stack is getting cleaned up as part of the process of throwing, so the compiler must make a copy that can continue to live beyond that point.

When you throw an object with new, you're not throwing the actual object but you're throwing a pointer to the object. That means your catch block must also catch a pointer rather than a reference. Don't forget to delete the pointer or you'll have a memory leak!

When the catch block uses throw; instead of throw e; it can reuse the copy it made earlier and there's no need to make another copy.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
0

It appears that you have misunderstood what re-throw means. When you do -

catch(CCLAError& e)
{
   throw e;
}

-- you are NOT rethrowing. Instead, as you have observed, you are indeed creating a copy of the new exception. Instead (again, as you have found for yourself), this is what is technically the correct way to re-throw:

catch(CCLAError& e)
{
   throw;
}

Read chapter 14 in Stroustrup's TC++PL (14.3.1 deals with rethrowing).

Also, you do NOT have to do -

throw new CCLAError( ... )

Instead, do -

throw CCLAError( ... )

-- like you were doing before, only receive by CONST reference (you cannot hold a reference to a temporary).

catch(const CCLAError &e)
Happy Green Kid Naps
  • 1,611
  • 11
  • 18
  • Concerning your last sentence: There are no temporaries: `CCLAError& e` will bind to the exception object. No copy needs to be made. Where do you think there is a temporary? – James McNellis Jun 01 '12 at 18:44
  • `throw CCLAError ( ... )` causes the LNK2001 linker error described in the OP. – johnluetke Jun 01 '12 at 20:05
-1

The language specification allows the compilers to make as many copies of the original object as they want. There is no restriction on the number of copies.

That means, your custom exception class must have an accessible copy-constructor, either the compiler generated one, or user-defined one.

Nawaz
  • 353,942
  • 115
  • 666
  • 851