On Sep 24, 4:10 pm, Emil Berg <emilbe...@gmail.com> wrote:
On Sep 24, 4:25 pm, Gert-Jan de Vos <gert-
jan.de....@onsneteindhoven.nl> wrote:
On Sep 24, 12:02 pm, Emil Berg <emilbe...@gmail.com> wrote:
What I want to do is pass exceptions between threads. I have some
exception classes that derive from CBaseException class.
See here for an elegant solution that works in C++98:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2106.html
Basically in your CBaseException class, define virtual clone() and
throw() functions.
No your thread library can clone() exception objects across thread
boundaries and
re-throw the exception in the new thread. The nice thing is that user
code doesn't
see the difference except that all your exception objects must
implement both
support functions. You can make a simple template to help with that.
This post is exactly what I'm doing :)
But still there is a memory leak in their example, because when
exception is cloned and then thrown, it is caught with reference type
and not deleted.
You don't throw the cloned object directly. I suggest to wrap the
cloned
exception object from clone() in an auto_ptr:
auto_ptr<cloneable_exception> clone();
This returns new ConcreteException(*this) for all your
ConcreteException::clone() implementations.
Now the ownership of the new-ed ConcreteException object is with your
thread library. In the destination thread, your thread library calls
dynamic_throw() on the cloned exception object.
Now each ConcreteException in turn implements this:
void ConcreteException::dynamic_throw() { throw *this; }
Such that your cloned exception gets re-thrown by value again. The
auto_ptr that owned the cloned exception will clean up after the throw
resulting from dynamic_throw().
You can easily support this in your thread library by
having a catch (cloneable_exception&) handler in your library's thread
start function.
You see that the new-ed clone and pointers can be hidden in your
thread
library while the user just sees idiomatic exception objects by value.
There is one extra copy (clone) to transport the exception object over
the thread boundary and one possible extra copy for storing the
exception
object while the second thread's call stack unwinds.