Edit Question - KnowledgeHub

Title Body

I've just fixed a very subtle bug in our code, caused by slicing of an exception, and I now want to make sure I understand exactly what was happening. Here's our base exception class, a derived class, and relevant functions: class Exception { public: // construction Exception(int code, const char* format="", ...); virtual ~Exception(void); <snip - get/set routines and print function> protected: private: int mCode; // thrower sets this char mMessage[Exception::MessageLen]; // thrower says this FIXME: use String }; class Derived : public Exception { public: Derived (const char* throwerSays) : Exception(1, throwerSays) {}; }; void innercall { <do stuff> throw Derived("Bad things happened!"); } void outercall { try { innercall(); } catch(Exception& e) { printf("Exception seen here! %s %d\n", __FILE__, __LINE__); throw e; } } The bug was of course that outercall ends up throwing an Exception, instead of a Derived. My bug resulted from higher in the call stack attempts to catch the Derived failing. Now, I just want to make sure I understand - I believe that at the 'throw e' line, a new Exception object is being created, using a default copy constructor. Is that what's really going on? If so, am I allowed to lock out copy constructors for objects that will be thrown? I'd really prefer this not happen again, and our code has no reason to copy Exception objects (that I know of). Please, no comments on the fact that we have our own exception hierarchy. That's a bit of old design that I'm working to correct (I'm making good progress. I've gotten rid of the home-grown string class, and many of the home-grown containers.) UPDATE: To be clear, I had fixed the bug (by changing 'throw e' to 'throw') before I ever asked the question. I was just looking for confirmation of what was going on.

Tags (comma-separated) Cancel