
----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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