----- Original Message ----- From: "Emil Dotchevski" <emil@revergestudios.com> To: <boost@lists.boost.org> Sent: Monday, September 01, 2008 9:51 PM Subject: Re: [boost] [exception][policy]
On Sun, Aug 31, 2008 at 11:33 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Can my original idea of exception registry be implemented by the Boost.Exception library?
What are the benefits of the "exception registry" over the "function wrapper" approach that you mentioned?
Maybe my initial "exception registry" proposal has some drawbacks and need to be pollished. The benefits I see are: * The exception_registry will be done once for all and will profit to every user of the exception_ptr library, while the wrapping approach forces every user to wrap its functions. * The wrapping approach has one try-catch block more than the exception_registry approach, so less performant. * The exception_registry approach centralize the knowledge of which compilers provides the mechanisms to ensure that current_exception works for any exception on the Boost.Exception library. The wrapping approach on the best case split this knowledge into two libraries, and if the try_catch functor class do not exists, into each user of the current_exception function direct or indirect. Do you see any benefits of the "function wrapper" over the "exception registry" approach? Please, let me know if you have a use case where the exception_registry proposal do not work? I'm really interested in seen if together we can get a better solution.
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. 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? Best, Vicente