您对在 C++ 中未找到抛出异常有何看法？

Question

我知道大多数人认为这是一种不好的做法，但是当你试图让你的类公共接口仅与引用一起使用，仅在必要时才将指针保留在内部时，我认为没有办法返回某些内容告诉您正在查找的值在容器中不存在。

class list {
    public:
        value &get(type key);
};

假设您不想在类的公共接口中看到危险的指针，在这种情况下如何返回 not find 并抛出异常？

你对此有何看法？ 您是否返回一个空值并检查它的空状态？ 我实际上使用了 throw 方法，但引入了一种检查方法：

class list {
   public:
      bool exists(type key);
      value &get(type key);
};

因此，当我忘记首先检查该值是否存在时，我会得到一个异常，这实际上是一个异常。

你会怎么做？

Answer 1

STL 通过使用迭代器来处理这种情况。 例如，std::map 类具有类似的功能：

iterator find( const key_type& key );

如果未找到键，则返回“end()”。 您可能想要使用此迭代器方法，或者对返回值使用某种包装器。

Answer 2

正确的答案（根据 Alexandrescu 的说法）是：

Optional 和 Enforce

首先，一定要使用访问器，但要以更安全的方式，而不需要发明轮子：

boost::optional<X> get_X_if_possible();

然后创建一个 enforce helper：

template <class T, class E>
T& enforce(boost::optional<T>& opt, E e = std::runtime_error("enforce failed"))
{
    if(!opt)
    {
        throw e;
    }

    return *opt;
}

// and an overload for T const &

这样，根据值的缺失可能意味着什么，您可以显式检查：

if(boost::optional<X> maybe_x = get_X_if_possible())
{
    X& x = *maybe_x;

    // use x
}
else
{
    oops("Hey, we got no x again!");
}

或隐式检查：

X& x = enforce(get_X_if_possible());

// use x

当您担心效率，或者当您想要在发生故障时处理故障时，可以使用第一种方法。 第二种方法适用于所有其他情况。

Answer 3

在这种情况下不要使用异常。 对于此类异常，C++ 具有不小的性能开销，即使没有抛出异常，而且它还使代码的推理变得更加困难（参见异常安全）。

C++ 的最佳实践是以下两种方法之一。 两者都在 STL 中使用：

• 正如 Martin 指出的，返回一个迭代器。 实际上，你的迭代器很可能是一个简单指针的 typedef ，没有什么反对它的； 事实上，由于这与 STL 一致，您甚至可以认为这种方式优于返回引用。
• 返回一个 std::pair。 但是，这使得修改该值变得不可能，因为调用了对的复制对象，而该复制对象不适用于引用成员。

/编辑：

这个答案引起了相当多的争议，从评论中可以看出，但从它得到的许多反对票中不那么明显。 我发现这相当令人惊讶。

这个答案从来都不是最终的参考点。 马丁已经给出了“正确”的答案：例外情况对本例中行为的反映相当差。 从语义上讲，使用其他一些信号机制比异常更有意义。

美好的。 我完全赞同这个观点。 无需再提一次。 相反，我想为答案提供一个额外的方面。 虽然微小的速度提升永远不应该成为任何决策的首要理由，但它们可以提供进一步的论据，并且在某些（少数）情况下，它们甚至可能至关重要。

实际上，我提到了两个方面：性能和异常安全。 我认为后者是没有争议的。 虽然提供强有力的异常保证非常困难（当然，最强的是“不抛出”），但我相信这是必要的：任何保证不抛出异常的代码都会使整个程序更容易推理。 许多 C++ 专家都强调这一点（例如 Scott Meyers 在《Effective C++》第 29 条中）。

关于速度。 Martin York 指出这在现代编译器中不再适用。 我谨表示不同意。 C++ 语言使得环境有必要在运行时跟踪在异常情况下可能展开的代码路径。 现在，这个开销实际上并没有那么大（并且很容易验证这一点）。 我上面的文字中的“不平凡”可能太强烈了。

然而，我发现区分 C++ 等语言和 C# 等许多现代“托管”语言很重要。 只要不抛出异常，后者就没有额外的开销，因为无论如何都会保留展开堆栈所需的信息。 总的来说，支持我的用词选择。

Answer 4

STL 迭代器？

我之前提出的“迭代器”想法很有趣，但迭代器的真正意义在于通过容器进行导航。 不是一个简单的访问器。

如果您的访问器是众多访问器之一，那么迭代器就是最佳选择，因为您将能够使用它们在容器中移动。 但是如果你的访问器是一个简单的 getter，能够返回值或者没有值，那么你的迭代器可能只是一个美化的指针

......引导我们...

智能指针？

智能指针的目的是简化指针所有权。 使用共享指针，您将获得一个将被共享的资源（内存），但要付出一定的开销（共享指针需要分配一个整数作为引用计数器......）。

你必须选择：要么你的值已经在共享指针内，然后，你可以返回这个共享指针（或弱指针）。 或者您的值位于原始指针内。 然后您可以返回行指针。 如果您的资源尚未位于共享指针内，您不想返回共享指针：当您的共享指针超出范围并在不通知的情况下删除您的值时，将会发生一系列有趣的事情你...

:-p

指针？

如果您的接口清楚其资源的所有权，并且事实上返回值可以为 NULL，那么您可以返回一个简单的原始指针。 如果你的代码的用户足够愚蠢，忽略了你的对象的接口契约，或者用你的指针进行算术或其他任何事情，那么他/她将足够愚蠢地破坏你选择返回值的任何其他方式，所以不要理会智障人士...

未定义的值

除非您的值类型确实已经具有某种“未定义”值，并且用户知道这一点，并且会接受处理该值，否则这是一个可能的解决方案，类似于指针或迭代器解决方案。

但是，不要将“未定义”值添加到您的值类因为您提出的问题：您最终会将“引用与指针”战争提升到另一个疯狂的程度。 代码用户希望您提供给他们的对象要么正常，要么不存在。 必须测试该对象的所有其他代码行是否仍然有效是一件痛苦的事情，并且由于您的错误，将毫无用处地使用户代码变得复杂。

例外

例外通常并不像某些人希望的那样代价高昂。 但对于简单的访问器来说，如果您的访问器经常使用，则成本可能不小。

例如，STL std::vector 有两个通过索引访问其值的访问器：

T & std::vector::operator[]( /* index */ )

和：

T & std::vector::at( /* index */ )

区别在于 [] 是非抛出< /i> . 因此，如果您访问向量的范围之外，您就得靠自己了，可能会面临内存损坏和迟早崩溃的风险。 因此，您应该真正确保您使用它验证了代码。

另一方面，at 是抛出。 这意味着如果您访问向量的范围之外，那么您将得到一个干净的异常。 如果您想将错误的处理委托给另一个代码，则此方法更好。

当我访问循环内的值或类似的东西时，我个人使用 [] 。 当我觉得异常是返回当前代码（或调用代码）（出现问题的事实）的好方法时，我使用 at 。

所以呢？

在您的情况下，您必须选择：

如果您确实需要闪电般快速的访问，那么投掷访问器可能会成为问题。 但这意味着您已经在代码上使用了分析器来确定这是瓶颈，不是吗？

;-)

如果您知道没有值的情况经常发生，并且/或者您希望客户端将可能的 null/无效/任何语义指针传播到所访问的值，则返回一个指针（如果您的值位于一个简单的值中）指针）或弱/共享指针（如果您的值由共享指针拥有）。

但是，如果您认为客户端不会传播此“空”值，或者他们不应该在其代码中传播 NULL 指针（或智能指针），那么请使用受异常保护的引用。 添加一个返回布尔值的“hasValue”方法，并在用户尝试获取值（即使没有值）时添加一个抛出。

最后但并非最不重要的一点是，考虑对象的用户将使用的代码：

// If you want your user to have this kind of code, then choose either
// pointer or smart pointer solution
void doSomething(MyClass & p_oMyClass)
{
   MyValue * pValue = p_oMyClass.getValue() ;
   
   if(pValue != NULL)
   {
      // Etc.
   }
}

MyValue * doSomethingElseAndReturnValue(MyClass & p_oMyClass)
{
   MyValue * pValue = p_oMyClass.getValue() ;
   
   if(pValue != NULL)
   {
      // Etc.
   }

   return pValue ;
}

// ==========================================================

// If you want your user to have this kind of code, then choose the
// throwing reference solution
void doSomething(MyClass & p_oMyClass)
{
   if(p_oMyClass.hasValue())
   {
      MyValue & oValue = p_oMyClass.getValue() ;
   }
}

因此，如果您的主要问题是在上面的两个用户代码之间进行选择，那么您的问题不是性能问题，而是“代码人体工程学”。 因此，不应因为潜在的性能问题而放弃异常解决方案。

:-)

Answer 5

contains() 的问题在于，您最终将搜索两次确实存在的东西（首先检查它是否在那里，然后再次找到它）。 这是低效的，特别是如果（正如其“列表”名称所示）您的容器的搜索时间为 O(n)。

当然，您可以进行一些内部缓存来避免双重搜索，但是您的实现会变得更加混乱，您的类变得不那么通用（因为您已经针对特定情况进行了优化），并且它可能不会是异常安全或线程的-安全的。

Answer 6

返回一个shared_ptr作为结果怎么样？ 如果未找到该项目，则该值可能为空。 它的工作方式类似于指针，但它会为您释放对象。

Answer 7

（我意识到这并不总是正确的答案，而且我的语气有点强硬，但您应该在决定其他更复杂的替代方案之前考虑这个问题）：

那么，什么是返回指针错误？

我在 SQL 中多次看到这种情况，人们会认真地从不处理 NULL 列，就像他们患有某种传染性疾病或其他什么一样。 相反，他们巧妙地提出了一个“空白”或“不存在”的人为值，例如 -1、9999 甚至“@X-EMPTY-X@”之类的值。

我的回答是：语言已经有了“不在那里”的结构； 来吧，不要害怕使用它。

Answer 8

附件？

我之前提出的“迭代器”想法很有趣，但迭代器的真正意义在于通过容器进行导航。 不是作为一个简单的访问器。

我同意paercebal，迭代器就是迭代。 我不喜欢STL 的方式。 但访问器的想法似乎更有吸引力。 那么我们需要什么呢？ 类似容器的类，感觉像是用于测试的布尔值，但行为类似于原始返回类型。 这对于演员操作员来说是可行的。

template <T> class Accessor {
    public:
        Accessor(): _value(NULL) 
        {}

        Accessor(T &value): _value(&value)
        {}

        operator T &() const
        {
            if (!_value)
               throw Exception("that is a problem and you made a mistake somewhere.");
            else
               return *_value;
        }

        operator bool () const
        {
            return _value != NULL;
        }

    private:
        T *_value;
};

现在，有什么可预见的问题吗？ 用法示例：

Accessor <type> value = list.get(key);

if (value) {
   type &v = value;

   v.doSomething();
}

Answer 9

@aradtke，你说。

我同意paercebal，迭代器是
迭代。 我不喜欢STL的方式
做。 但是访问器的想法
似乎更有吸引力。 那么我们需要什么呢？
一个类似容器的类，感觉就像
用于测试的布尔值，但行为类似于
原始返回类型。 那会
对于强制转换运算符来说是可行的。 [..] 现在，
有什么可预见的问题吗？

首先，您不需要 OPERATOR bool。 有关详细信息，请参阅Safe Bool 习语。 但是关于你的问题......

这就是问题，用户现在需要在案例中显式转换。 类似指针的代理（例如迭代器、ref-counted-ptrs 和原始指针）有简洁的“get”语法。 如果调用者必须使用额外的代码来调用转换运算符，则提供转换运算符并不是很有用。

从您的参考示例开始，最简洁的编写方式：

// 'reference' style, check before use
if (Accessor<type> value = list.get(key)) {
   type &v = value;
   v.doSomething();
}
// or
if (Accessor<type> value = list.get(key)) {
   static_cast<type&>(value).doSomething();
}

这没关系，不要误会我的意思，但它比它必须的更冗长。 现在考虑一下，如果我们知道，出于某种原因，list.get 将会成功。 然后：

// 'reference' style, skip check 
type &v = list.get(key);
v.doSomething();
// or
static_cast<type&>(list.get(key)).doSomething();

现在让我们回到迭代器/指针行为：

// 'pointer' style, check before use
if (Accessor<type> value = list.get(key)) {
   value->doSomething();
}

// 'pointer' style, skip check 
list.get(key)->doSomething();

两者都非常好，但指针/迭代器语法稍微短一点。 您可以为“引用”样式提供一个成员函数“get()”...但这已经是operator*() 和operator->() 的用途。

“指针”样式访问器现在具有运算符“未指定的布尔”、运算符*和运算符->。

你猜怎么着……原始指针满足这些要求，因此对于原型设计，list.get() 返回 T* 而不是 Accessor。 然后等list的设计稳定了，就可以回来写Accessor了，一个类似指针的Proxy< /a> 类型。

Answer 10

在这种情况下，我更喜欢做的是抛出“get”，对于那些性能问题或失败很常见的情况，有一个“tryGet”函数，类似于“bool tryGet(type key, value **pp)”约定是，如果返回 true，则 *pp == 指向某个对象的有效指针，否则 *pp 为 null。

Answer 11

有趣的问题。 我猜想在 C++ 中专门使用引用是一个问题 - 在 Java 中引用更灵活并且可以为空。 我不记得强制空引用是否是合法的 C++：

MyType *pObj = nullptr;
return *pObj

但我认为这很危险。 同样，在 Java 中，我会抛出异常，因为这在 Java 中很常见，但我很少看到在 C++ 中如此自由地使用异常。
如果我正在为可重用的 C++ 组件制作公共 API 并且必须返回引用，我想我会走异常路线。
我真正的偏好是让 API 返回一个指针； 我认为指针是 C++ 的一个组成部分。