Re: [boost] [exception][policy]

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-02 02:26:22

----- Original Message ----- 
From: "Emil Dotchevski" <emil_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 02, 2008 5:50 AM
Subject: Re: [boost] [exception][policy]

>
> On Mon, Sep 1, 2008 at 2:34 PM, vicente.botet <vicente.botet_at_[hidden]> 
> wrote:
>>> Do you have a use case where the
>>> "function wrapper" wouldn't work, but the "exception registry" would?
>>
>> No, not now. I was asking this only because I think that it is a better
>> solution to include it in the Exception library and also because you were
>> proposing this for the thread_pool library.
>
> In my mind both approaches are about the same, except that the wrapper
> approach is decoupled from the exception library. It's not that I like
> it better, but it can be implemented on top of the current exception
> library interface.

I would like to know which approach is prefered by the boost 
user/developpers, have some of you a preference?

> I certainly don't want to add anything to Boost Exception without
> knowing that someone has a use case for that.

You are right, it is a good principle. I have a use case with two 
possibilities. You have find that it was a possibility for a thread_pool 
library for which a more coupled approach was not a problem. This thread was 
started because the throw_exception function has coupled to the 
Boost.Exception library. A user could wrap the throw_exception function and 
do whatever you do in. What is the difference? What is wrong then in couplig 
a register_exception mechanis to ensure the *correct* semantics of the 
current_exception function?

>> Quotting you from your preceding
>> post : "Your function wrapper solution is a possibility. Another 
>> possibility
>> is, if the thread pool library is not third party, it can implement your
>> original idea of exception registry." So, if you think that this could be 
>> a
>> possibility for the thread_pool library, it should be even better for the
>> exception library, because in this way, other libraries will profit of 
>> this
>> commonality, isn't it?
>
> What is "the" thread_pool library we're talking about?

The thread_pool library of my use case of course. It can also be any library 
using the exception_ptr current_exception as the already proposed for review 
Future library (packaged_task) library by Anthony, the porting of the FTTask 
("A Java Fork/Join Framework"
http://gee.cs.oswego.edu/dl/papers/fj.pdf) to C++/boost I would like to do, 
...

I'd be interested in knowing what other boost::current_exception users 
think? Anthony?

Vicente