Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-08-30 08:29:20

----- Original Message -----
From: "Emil Dotchevski" <emil_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 29, 2008 8:57 PM
Subject: Re: [boost] [exception][policy]

> On Thu, Aug 28, 2008 at 9:21 PM, vicente.botet <vicente.botet_at_[hidden]>
> wrote:
>> The main problem comes from the fact exception_ptr current_exception() do
>> not works for any exception. So Emil has found that boost::throw could be
>> used to throw a boost::exception wrapping the intendeed exception. IMHO,
>> the
>> exception_ptr emulation (without language support) to transport
>> exceptions
>> between threads is not of real use if current_exception() do not works
>> for
>> any exception.
> As per
> current_exception works for any exception. This is what we should aim
> for.

Hi Emil,

Evidently when I said"exception_ptr current_exception() do
>> not works for any exception" I was talking about the current
>> implementation of exception_ptr current_exception() by the
>> Boost::Exception library. I'm aware that n2179 require that
>> current_exception MUST work for any exception. This is exactly what my
>> proposal intend to provide.
BTW, if current_exception works for any exception, we don't need anymore
that boost::throw_exception use boost::enable_current_exception, isn't it?
And in this case we can come back to the old behavior of
boost::throw_exception as requested by Robert.

> Antony has already provided a MSVC-specific implementation that works
> for any exception. As soon as I find the time to integrate this into
> Boost Exception, boost::enable_current_exception will be a noop on
> In principle, every compiler has the machinery necessary to implement
> current_exception completely non-intrusively. I am not a compiler
> expert, but it seems likely that compiler-specific solution should be
> possible for GCC as well.

I don't know every compiler so I prefere Boost::Exception provides a
solution that works when the compiler do not has the machinery necessary to
implement current_exception completely non-intrusively. Evidently, when the
compiler provide the mechanism, current_exception will not use the the
user_current_exception_handler, and the setting of this handlers will be a

> In my opinion boost::exception_ptr provides very useful functionality.
> It is enabled by boost::enable_current_exception, which
> boost::throw_exception allows us to inject non-intrusively. If the
> cost of boost::enable_current_exception is a problem, this can be
> viewed as a motivating force to provide compiler-specific
> non-intrusive support for boost::exception_ptr (however I request that
> we don't discuss the cost of boost::enable_current exception until I
> get a chance to fully test the refactoring pass I've done on the
> exception library.)

I'm not questioning the usefulness of boost::exception_ptr. I'm only stating
that in the current release, current_exception do not works for any
exception (do not transfer every exception between threads) as required by
n2179. What is worst is that the final user can not do anything for the
exceptions thrown by 3pp libraries that do not use
boost::enable_current_exception or boost::throw_exception.

My proposal allows the final user to complete *intrusively* the list of
exceptions for which current_exception will work, having as default behavior
the one of the current release. What objections do you have to my proposal?



Boost list run by bdawes at, gregod at, cpdaniel at, john at