c++
Why not capture the already propagating exception in `std::promise::~promise`
Say you have the following code void func(std::promise<int> prom) { try { auto promise = std::promise<int>{std::move(prom)}; // .. do stuff throw std::runtime_error{"something went wrong"}; } catch (...) { // cleanup and dont bother with the promise } } auto promise = std::promise<int>{}; auto future = promise.get_future(); std::thread{[promise = std::move(promise)] { func(std::move(promise)); }}.detach(); try { cout << future.get() << endl; } catch (std::exception& exc) { cerr << exc.what() << endl; } What is the reason behind not catching the exception that is propagating when the promise is destroyed and re-propagating the same exception on the future end? Why is a broken promise exception always thrown in such a situation? I just feel like its natural to have the same exception re-propagate on the future end. To clarify what I meant, in addition to having the set_exception() method, I thought the destructor calling set_exception(std::current_exception()) could be a good idea Upon catching the exception and storing a reference to it, the destructor would then rethrow the exception
A destructor has no exception to catch or rethrow. I think the logic you want is: If the destructor detects that it's being called as part of stack unwinding; and it would otherwise store a future_error with broken_promise in the shared state, then it stores current_exception() in the shared state instead. Let's ignore the fact that until C++17 you can't portably detect if you are being called as part of stack unwinding; implementations have access to "magic" things that mere mortals don't. First, you are sharing the exception object across threads silently, with all the attendant risks of data races. Sharing things across threads is hard enough without the standard library stabbing you in the back. Second, an exception on the producer's side may well be meaningless for the consumer. In many cases the consumer doesn't care if the producer failed to produce a value because of a network error or the phase of the moon. All it cares is that the promise was broken.
You propose that std::promise's destructor catch active exceptions and store them. What does do_stuff return under your proposal? int do_stuff(std::future& f) { std::vector<int> alice; std::promise bob; f = bob.get_future(); throw 7; alice.push_back(42); return alice[0]; } what does do_stuff return? The 7 thrown was catught in ~promise, but that bypasses the return value calculation. I see nothing but insanity down this path. Exceptions are already a come-from, but at least they are structured come-from. Your proposal requires unstructured catching and would make program flow of exceptions completely beyond anyone's ability to understand. If it simply duplicated the exception, in general you aren't allowed to do that? You can store a (smart) pointer to them, but not a copy.
Related Links
ambiguous overload C++ for operator = [closed]
Attribute value for missing optional boost::spirit::x3 rule
how to change array elements after initialization
Qt - C++ - Function of the child accessed through parent with connect
using a fixed size array in another array initialize list
tried to use thread on my server
C++ vector [] operator throws error while at() works
Clion multiple debug configurations in cmake
C++ String object wrong characters [duplicate]
Syntex of Constructor Defining
Storing a child-class pointer in a map of parent-class pointer
In a composition relationship, can a member call a parent method?
Is it use an initialize a iterator of vector with a pointer in C++ in an init function?
How Do I Make My Program in Qt Continually Send A String to My Arduino?
C++ exception int catch block executes when string exception was thrown
why does it go wrong after push_back?