From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-06 12:42:08
From: "William E. Kempf" <williamkempf_at_[hidden]>
>
> If you can devise a method that relies only on copy construction and
allows
> reference types I'd love to see it. I'd have no objections at that point.
See George Heintzelman's post. The general idea is that
R r;
is replaced with
char r[sizeof(R)];
(except that it needs to be properly aligned, so we'd need a
boost::aligned_storage) and
r = f();
is replaced with
new(&r) R(f());
References would need to be converted temporarily to pointers, but _seems_
possible.
> > terminate() is invoked when there is no matching exception handler. If
> > join() magically transports exceptions across thread boundaries, the
> > exception thrown in main() will be caught by the join()ing thread, and
> > things are fine and dandy.
>
> How can they be caught in the joining thread if terminate() is called, as
> the standard says it must be?
Fair point, but how many real world programs leave exceptions uncaught in
order to call terminate()?
> > Unfortunately, when there is no join(), the uncaught exception must
> > terminate the process, but we don't know in advance whether there will
be
> a
> > join() sometimes in the future!
>
> True, so the issues are related and both issues are terrible, IMHO, and
are
> the crux of why I don't think it's appropriate to propogate exceptions out
> of a thread.
There are definitely some good arguments for calling terminate() when a
thread allows an exception to escape; on the other hand, intra-thread
exceptions are an useful form of communication, just like with ordinary
function calls. Difficult choice.
A hybrid solution is also possible, if a thread keeps track of its handles.
If an exception escapes, and no handles are alive, nobody can join() and
it's terminate() time.