Boost logo

Boost :

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" to C++/boost I would like to do,

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


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