为什么不在`std::promise::~promise`中捕获已经传播的异常

Question

假设你有以下代码

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;
}

当 Promise 被销毁并在未来结束时重新传播相同的异常时，没有捕获正在传播的异常的原因是什么？为什么在这种情况下总是抛出一个破承诺异常？

我只是觉得在未来重新传播相同的异常是很自然的。

---

为了澄清我的意思，除了set_exception() 方法之外，我认为调用set_exception(std::current_exception()) 的析构函数可能是个好主意

在捕获异常并存储对它的引用后，析构函数将重新抛出异常

Answer 1

析构函数没有异常可以捕获或重新抛出。我认为你想要的逻辑是：

• 如果析构函数检测到它作为堆栈展开的一部分被调用；和
• 否则它将以共享状态存储 future_error 和 broken_promise，然后
• 它将current_exception() 存储在共享状态。

让我们忽略这样一个事实，在 C++17 之前，您无法以可移植的方式检测您是否被作为堆栈展开的一部分调用；实现可以访问普通人无法访问的“神奇”事物。

首先，您在线程之间默默地共享异常对象，伴随着数据竞争的所有风险。如果没有标准库在背后捅你一刀，跨线程共享东西就够难了。

其次，生产者方面的例外可能对消费者来说毫无意义。在许多情况下，消费者并不关心生产者是否由于网络错误或月相而未能产生价值。它只在乎承诺被打破了。

Answer 2

您建议std::promise 的析构函数捕获活动异常并存储它们。

do_stuff 根据你的提议返回什么？

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];
}

do_stuff 返回什么？抛出的7 被~promise 捕获，但这绕过了返回值计算。

我在这条路上看到的只有精神错乱。

异常已经是来自，但至少它们是结构化来自。您的提议需要非结构化捕获，并且会使异常程序流完全超出任何人的理解能力。

如果它只是复制了异常，一般情况下你不允许这样做吗？您可以存储指向它们的（智能）指针，但不能存储副本。