| 2 | | > This is a fairly annoying problem for me as well, especially when writing code where you don't have control over the exception that's thrown -- all you want to do is intercept the exception by calling std::current_exception and set the promise. I need to use boost::futures because of facilities like wait_for_any, but the fact that it implies no longer being able to capture arbitrary exceptions is a fairly annoying problem. What exactly is the issue right now that prevents adding a std::exception_ptr overload when available? It seems like in the case that std::exception_ptr is available, boost::future/promise could deal with std::exception_ptr internally instead of boost::exception_ptr, correct? Both overloads could be provided (one for std::exception_ptr and one for boost::exception_ptr) since converting boost::exception_ptr to std::exception_ptr should be a much simpler conversion than the other way around and can be done inside the implementation of boost::promise. Perhaps I'm missing some subtleties, though? |
