----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html current_exception works for any exception. This is what we should aim for.
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
Hi Emil, Evidently when I said"exception_ptr current_exception() do 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 MSVC.
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 noop.
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? Regards, Vicente