From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-13 08:24:12
Hrm, it's interesting that Stroustrup writes "... it would be a mistake to
assume that every exception derived from exception is a standard library
exception...", when elsewhere I believe that it is frowned upon. My point
is, that user exceptions likely aren't derived from std::exception and
shouldn't be. It would be a big mistake for Boost.Threads to only support
std::exceptions, especially since an already demonstrated implementation
does not preclude user defined types. (While it would be possible to create
a throws_std_exceptions policy, it would probably be too limited for
inclusion in boost.)
Another Stroustrup quote :) "A library shouldn't unilaterally terminate a
program. Instead, throw an exception and let a caller decide."
(I'd refer to Josuttis's book to see what you're talking about, but since it
was a requirement in a course I co-designed, I found it to be one of the
most unreadable references available--I traded it in at a used bookstore.)
----- Original Message -----
From: Victor A. Wagner, Jr.
Sent: Tuesday, 2002:August:13 3:17 AM
Subject: Re: Re: Attempting resolution of Threads & Exceptions Issue
At Monday 2002/08/12 16:31, you wrote:
>----- Original Message -----
>From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> > [Un?]fortunatly, as far as I know, the end user is required to specifiy
> > exceptions they would like propagated.
>Are they? If we agree to this, then the argument that others have made
>about library threads terminating is now a complete non-argument... unless
>you expect to be able to specify the (theoretically) infinite number of
>exceptions that could occur.
>But I'm not sure this premise is true. The easiest implementation would be
>to convert all unhandled exceptions into a single thread_terminated
>exception during propogation (possibly being nice enough to duplicate the
>what() results of std::exceptions). Even if we go the extra mile of
>providing propogation of specified exception types as-is, we can still
>translate all other exception types as thread_terminated, or in this case a
>better named unexpected_thread_termination.
I'd vote for (and help implement) a duplication of ALL of the
std::exceptions mentioned in Nicolai Josuttis's book (section 3.3.1) and
any others which may be in the standard (deriving from std::exception) and
not mentioned in "The C++ Standard Library".
>Unsubscribe & other changes:
Victor A. Wagner Jr. http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
"There oughta be a law"
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