Re: [Boost-users] [Boost.thread] Exception handling strategy ?

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-07-24 12:38:14

----- Original Message ----- 
From: "Emil Dotchevski" <emil_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Monday, July 21, 2008 11:44 PM
Subject: Re: [Boost-users] [Boost.thread] Exception handling strategy ?

>
> On Mon, Jul 21, 2008 at 9:55 AM, vicente.botet <vicente.botet_at_[hidden]> 
> wrote:
>> If I understood, the MSVC-specific code allows the user to get the 
>> current
>> exception without throwing the exception with
>> boost::enable_current_exception(). What is the advantage if we can not
>> profit of this mechanism with other compilers?
>
> Adding support for MSVC doesn't prevent or make it more difficult to
> add similar support for GCC and other compilers. Antony's
> implementation is a good example to follow, IMO.

It is only a portability issu. If the user compiles with MSVC, it will be 
able to recover every exception thrown using current_exception, which is not 
the case for other compilers.

>> A few months ago I proposed an intrusive way allowing the user to define
>> which exceptions where wrapped by boost::exception_ptr. IMHO, the
>> exception_ptr emulation (without language support) to transport 
>> exceptions
>> between threads is not of real use if the user can not configurate the
>> exceptions that can be thrown by 3pp as the Exception library do already 
>> for
>> the STL exceptions.
>
> I don't consider what the exception library does for STL exceptions
> very valuable. It can even be argued that it's fundamentally flawed in
> that it erases the actual exception type in case someone throws (for
> example) an exception that derives std::logic_error.

Why not complete the list?

> Still, it is a reasonable workaround for the lack of language support.
> As last resort, you get an object of type boost::unknown_exception.
> This at least guarantees that no exception gets ignored.

Why to manage with a boost::unknown_exception. whenwe can have the thown 
exception using my proposal?

>> For recall, my proposal was the following:
>> The exception library defines a macro such as:
>>
>> #define BOOST_EXCEPTION_CATCH_RETURN(EXCP) \
>> catch( EXCP & e ) { \
>> return exception_detail::current_exception_unknown_boost_exception(e); \
>> }
>>
>> The current_exception function has a USER_SLOT used us follows
>>
>> inline exception_ptr
>> current_exception()
>> {
>>   try
>>   {
>>       throw;
>>   }
>>   catch(
>>       exception_detail::cloning_base & e )
>>   {
>>       exception_detail::clone_base const * c = e.clone();
>>       BOOST_ASSERT(c!=0);
>>       return exception_ptr(c);
>>   }
>>   catch(
>>       std::invalid_argument & e )
>>   {
>>       return exception_detail::current_exception_std_exception(e);
>>   }
>>   // ... as before
>> #ifdef BOOST_EXCEPTION_USER_SLOT
>> #include BOOST_EXCEPTION_USER_SLOT
>> #endif
>>   catch( ... )
>>   {
>>       return exception_detail::current_exception_unknown_exception();
>>   }
>
> I don't see the benefit of using a macro to inject this functionality
> into Boost. Instead, you could do something along the lines of (note,
> this won't work for abstract foo or bar):
>
> try
> {
>  try
>  {
>    //call functions that throw without using 
> boost::enable_current_exception
>  }
>  catch( foo & e )
>  {
>    throw boost::enable_current_exception(e);
>  }
>  catch( bar & e )
>  {
>    throw boost::enable_current_exception(e);
>  }
> }
> catch( ... )
> {
>  boost::exception_ptr ep=boost::current_exception();
>  ...
> }

Yes you are right, I can do it, but what can I do if I use the Future 
library which manage internally the current_exception? I think that I can't, 
or maybe I'm missing something.

Vicente