On Sun, Aug 31, 2008 at 8:54 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
On Sat, Aug 30, 2008 at 7:21 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
What use case do you have in mind?
Sorry, but I dont understand your question. What use case do I have in mind for what? Maybe you can question is related to:"What is worst is that the final user can not do anything for the exceptions thrown by 3pp libraries that do not use boost::enable_current_exception or boost::throw_exception."
I am trying to be as objective as possible in answering your previous questions. For that, I need to understand what is the use case you have in mind. I understand that it involves a 3rd party library throwing an exception, but more details please:
My own application request a thread pool library to execute a function F asynchronously
- who catches the exception initially?
A thread pool (packaged_task) library, which calls the function F calling a 3pp function 3ppF throwing an exception (3pp_exception1 or 3pp_exception2)
- who copies it into an exception_ptr?
the same thread pool (packaged_task) library calls the current_exception and stores the exception_ptr in the future associates to the packaged task.
- who rethrows it?
The thread pool (packaged_task) Library which rethrow the stored exception when the user wait on the future value.
- who catches it after the rethrow?
My own application, which requested a thread pool library to execute the function F
Emil, while answering your question I see that I was wrong when I said that "final user can not do anything for the exceptions thrown by 3pp libraries": The final user can define a function Ftry_catch wich wraps the call to the function F by a try-catch, use the boost:throw_exception to throw each one of the exceptions 3ppF can throw, and request the thread pool library to execute the function Ftry_catch instead. Was this what you mean?
I didn't mean anything in particular, I just wanted to understand the problem you are trying to solve. :) 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. Such use cases are supported by boost::copy_exception: catch( something & x ) { boost::exception_ptr p=boost::copy_exception(x); ... } Note however that after an exception is thrown without using boost::enable_current_exception, it is already too late for a general solution because it might be unsafe or impossible to copy the type you catch. For example, this will not work: catch( boost::exception & x ) { boost::exception_ptr p=boost::copy_exception(x); } You'd get a compile error, because boost::exception is abstract. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode