std::bad_Optional_access 是针对异常的小犯罪吗？

If std::optional's value()成员函数被调用时optional没有初始化实际值，astd::bad_optional_access被抛出。因为它直接源自std::exception，你需要catch (std::bad_optional_access const&) or catch (std::exception const&)用于处理异常。然而，这两种选择对我来说似乎都很悲伤：

• std::exception捕获每一个异常
• std::bad_optional_access公开实施细节。考虑以下示例：

Placement Item::get_placement() const {
  // throws if the item cannot be equipped
  return this->placement_optional.value();
}
void Unit::equip_item(Item acquisition) {
  // lets the exception go further if it occurs
  this->body[acquisition.get_placement()] = acquisition;
}

// somewhere far away:
try {
  unit.equip_item(item);
} catch (std::bad_optional_access const& exception) { // what is this??
  inform_client(exception.what());
}

因此，要捕获异常，您需要充分了解std::optional in the Item的实施，导致了一系列已知问题。我也不想抓住并重新包装std::bad_optional_access因为（对我来说）例外的关键部分是在需要之前忽略它们的可能性。这就是我认为正确的方法：

std::exception
  <- std::logic_error
    <- std::wrong_state (doesn't really exist)
      <- std::bad_optional_access (isn't really here)

因此，“遥远”的例子可以写成这样：

try {
  unit.equip_item(item);
} catch (std::wrong_state const& exception) { // no implementation details
  inform_client(exception.what());
}

Finally,

• Why is std::bad_optional_access设计得像这样吗？
• 我对异常的感觉正确吗？我的意思是，它们是为了这种用途而引入的吗？

Note: boost::bad_optional_access源自于std::logic_error. Nice!

注2：我知道catch (...)并投掷除以下类型以外的物体std::exception家庭。为了简洁（和理智），它们被省略。

更新：不幸的是，我不能接受两个答案，所以：如果你对这个话题感兴趣，你可以阅读胡作典的回答和他们的评论。

您说异常的主要吸引力在于您可以在调用堆栈的尽可能深处忽略它们。据推测，考虑到您希望避免泄漏实现细节，您不能再让异常传播超出其处理程序无法理解和修复的范围。这似乎与您的理想设计相矛盾：它致力于向用户修复异常，但是bad_optional_access::what完全没有关于刚刚发生的事情的上下文——向用户泄露实现细节。当用户看到的最多只是“无法装备物品：bad_Optional_access”时，您如何期望用户针对装备失败采取有意义的操作？

显然你已经过度简化了，但挑战仍然存在。即使有“更好”的异常层次结构，std::bad_optional_access只是没有足够的上下文，除了非常接近的调用者之外的任何东西都可能知道如何处理它。

您可能想要抛出几种截然不同的情况：

1. 您希望在没有太多语法开销的情况下中断控制流。例如，您有 25 个不同的选项需要解包，并且您希望在其中任何一个失败时返回一个特殊值。您在 25 个访问周围放置了一个 try-catch 块，为自己节省了 25 个if blocks.
2. 您已经编写了一个通用库，该库执行了许多可能出错的操作，并且您希望向调用程序报告细粒度错误，以使其有最好的机会以编程方式执行一些智能恢复操作。
3. 您已经编写了一个执行非常高级任务的大型框架，因此您通常期望操作失败的唯一合理结果是通知用户操作已失败。

当您遇到感觉不正确的异常问题时，通常是因为您正在尝试处理一个与您希望的运行级别不同的错误。希望更改异常层次结构只是试图使该异常符合您的特定用途，这会导致与其他人如何使用它的紧张关系。

显然，C++ 委员会认为bad_optional_access属于第一类，你问为什么它不属于第三类。我认为您应该翻转问题并问自己要捕获异常的目的是什么，而不是尝试忽略异常直到您“需要”对它们执行某些操作。

如果答案确实是“用户”，那么你应该抛出一些不是bad_optional_access相反，它具有高级功能，例如本地化错误消息和足够的数据inform_user能够打开一个带有有意义的标题、主文本、副文本、按钮、图标等的对话框。

如果答案是这是一般游戏引擎错误并且可能在游戏的常规过程中发生，那么您应该抛出一些内容，表明装备该物品失败，而不是存在状态错误。与无法描述的状态错误相比，您更有可能从未能装备物品中恢复，包括如果您需要为用户产生一个漂亮的错误。

如果答案是您可能会尝试连续装备 25 件物品，并且一旦出现问题就想停止，那么您无需进行任何更改bad_optional_access.

另请注意，不同的实现使不同的使用或多或少变得方便。在大多数现代 C++ 实现中，不抛出异常的代码路径没有性能开销，并且huge抛出路径上的开销。这通常会阻碍对第一类错误使用异常。