From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-13 08:55:09
How is that "reasonable" when all of the details of the propagated_exception
can be handled and encapsulated by the thread template?
Without specifying the exceptions that need to be explicitly caught by the
thread, for any exception that is not an std::exception, the thread will
have to throw something generic or terminate. Else, the user will have to
change their throwing technique to wrap all their exceptions into the
passable type (propagated_exception) and be sentient of those as well, which
requires the user to rewrite their boost::function that they pass to be
executed (introducing a threaded version and a non-threaded version)!
Stronger: It is already known that the exact exceptions can be specified and
rethrown exactly as stated. Anything lesser than that is unacceptable
now--from an implementation perspective and the user perspective.
----- Original Message -----
From: Peter Dimov
Sent: Tuesday, 2002:August:13 9:31 AM
Subject: Re: Re: Re: Attempting resolution of Threads & ExceptionsIssue
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> Sure, the details of how to handle unexpected exceptions are up for
> Originally, bad_exception seemed fitting to me, but giving std::exceptions
> special treatment by borrowing its .what () can be useful. Have you
> my implementation?
> Anyhow, a boost::tuple is used to list the exceptions (which AFAIK
> infinite recursion, limited by the compiler of course). My proposed
> implementation only accepted up to 10 exceptions as parameters to the
> throws_exceptions policy, however, the user could easily construct their
> tuple for which they would like the boost::thread to support.
I think that a reasonable course of action is to specify that join throws
"an implementation defined exception" that may or may not be the real
exception caught in the thread.
The portable implementation can enumerate all standard exception types
explicitly, and it can test whether the exception is-a
virtual auto_ptr<propagated_exception> clone() const = 0;
virtual void throw_this() const = 0;
in order to propagate arbitrary exceptions. The rest would have to be
translated to thread_exception (or however it's called.)
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk