假设我想使用C++23中提供的new std::expected<T, E> mechanism，并带有一个函数：
using E = /* domain-specific error type regarding getting Foo's */
std::expected<Foo, E> getFoo(/* whatever */);字符串
但是假设getFoo()的代码可能会抛出一个异常，因为我的内存不足，或者std::unordered_map抛出一个异常，因为我查找了一个不存在的键（我没有预料到，也不能与特定于域的东西相关）等等。
我应该扩展我的E类型来包括所有这些类型的异常吗？我应该把它们“ Package ”在一种E类型的元素中吗（也许使用子类型）？我应该让这些异常像往常一样传播，而只为特定于域的错误保留E吗？
以上的行动方式中只有一种是惯用的，还是要视情况而定？你能提出一些处理这种情况的经验法则吗？
1条答案
按热度按时间pkbketx91#
你问的是两种不同的情况：内存不足错误和其他错误。
当涉及到OOM时，唯一真实的问题是：您是否希望这种情况对您的应用程序来说是“可生存的”？对于大多数程序来说，答案是“否”。因此，让异常到达
main或其他合理的地方是合理的。当涉及到其他异常时，这些都是你可以选择的事情。你可能无法将“不存在的键”异常转换为你的域错误，但你可以选择是否使用抛出这种异常的API。或者你可以选择不这样做。同样，这是一个你是否希望这是一个可生存的条件的问题。
例如，如果用户给了你一个你期望在map中存在的字符串，但它不在那里，那么这是他们的错误，向他们暴露这个错误应该是你的错误集的一部分。但是如果这种情况代表你的内部编程错误，那么终止是有意义的。
这不是你可以理论化的东西，你必须将它应用于每个应用程序和用例的特定环境。