c++ - 你(真的)编写异常安全代码吗？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




异常处理 (EH) 似乎是当前的标准，通过搜索网络，我找不到任何试图改进或替换它的新想法或方法(嗯，存在一些变化，但没有什么新奇)。

虽然大多数人似乎忽略它或只是接受它，EH 有 一些巨大的缺点:异常对代码是不可见的，它会创建很多很多可能的退出点。乔尔在软件上写了一篇 article about it .与 goto 的比较非常合身，这让我又想起了 EH。

我尽量避免 EH，只使用返回值、回调或任何适合目的的东西。但是当你不得不写出可靠的代码时，你现在不能忽视 EH :它以 new 开头，这可能会引发异常，而不是仅仅返回 0(就像过去一样)。这使得任何 C++ 代码行都容易出现异常。然后 C++ 基础代码中的更多地方抛出异常...... std lib 做到了，依此类推。

这感觉就像 在摇摇欲坠的地面上行走 .. 所以，现在我们不得不处理异常了!

但是很难，真的很难。您必须学习编写异常安全的代码，即使您有一定的经验，仍然需要仔细检查任何一行代码以确保安全!或者你开始在任何地方放置 try/catch 块，这会使代码变得困惑，直到它达到不可读的状态。

EH 取代了旧的干净的确定性方法(返回值..)，该方法只有一些但可以理解且易于解决的缺点，这种方法会在您的代码中创建许多可能的退出点，并且如果您开始编写捕获异常的代码(在某些时候被迫这样做)，然后它甚至会在您的代码中创建多个路径(catch 块中的代码，考虑一个服务器程序，其中您需要除 std::cerr 之外的日志记录工具......)。 EH 有优势，但这不是重点。

我的实际问题:

你真的会写异常安全的代码吗？

您确定您最后的“生产就绪”代码是异常安全的吗？

你甚至可以确定，它是吗？

您知道和/或实际使用有效的替代品吗？

Answer 1

您的问题断言，“编写异常安全的代码非常困难”。我会先回答你的问题，然后再回答背后隐藏的问题。
回答问题

Do you really write exception safe code?

我当然是了。
这就是 Java 作为 C++ 程序员(缺乏 RAII 语义)对我失去很多吸引力的原因，但我离题了:这是一个 C++ 问题。
事实上，当您需要使用 STL 或 Boost 代码时，这是必要的。例如，C++ 线程( boost::thread 或 std::thread )将抛出异常以正常退出。

Are you sure your last "production ready" code is exception safe?

Can you even be sure, that it is?

编写异常安全的代码就像编写无错误的代码。
您不能 100% 确定您的代码是异常安全的。但是，您会为之努力，使用众所周知的模式，并避免使用众所周知的反模式。

Do you know and/or actually use alternatives that work?

C++ 中没有可行的替代方案(即您需要恢复到 C 并避免使用 C++ 库，以及像 Windows SEH 这样的外部意外)。
编写异常安全代码
要编写异常安全代码，你必须知道 第一 您编写的每条指令的异常安全级别是多少。
例如， new可以抛出异常，但分配内置(例如 int 或指针)不会失败。交换永远不会失败(永远不要写抛出交换)， std::list::push_back可以扔...
异常保证
首先要了解的是，您必须能够评估所有函数提供的异常保证:

无 :你的代码永远不应该提供。此代码将泄漏所有内容，并在抛出的第一个异常处崩溃。

基本 : 这是你起码必须提供的保证，即如果抛出异常，不泄漏资源，所有对象仍然是完整的

强 : 处理要么成功，要么抛出异常，但如果抛出，那么数据将处于与处理完全没有开始相同的状态(这赋予 C++ 事务处理能力)

nothrow/nofail : 处理会成功。

代码示例
下面的代码似乎是正确的 C++，但实际上，提供了“无”保证，因此，它是不正确的:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   X * x = new X() ;                // 2. basic : can throw with new and X constructor
   t.list.push_back(x) ;            // 3. strong : can throw
   x->doSomethingThatCanThrow() ;   // 4. basic : can throw
}

我在编写所有代码时都考虑到了这种分析。
提供的最低保证是基本的，但是，每条指令的顺序使整个函数“无”，因为如果 3. throws，x 将泄漏。
首先要做的是使函数“基本”，即将 x 放在智能指针中，直到它被列表安全地拥有:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   std::auto_ptr<X> x(new X()) ;    // 2.  basic : can throw with new and X constructor
   X * px = x.get() ;               // 2'. nothrow/nofail
   t.list.push_back(px) ;           // 3.  strong : can throw
   x.release() ;                    // 3'. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 4.  basic : can throw
}

现在，我们的代码提供了“基本”保证。什么都不会泄漏，所有对象都将处于正确状态。但我们可以提供更多，也就是强有力的保证。这就是它可能变得昂贵的地方，这就是为什么 并非所有 C++ 代码很强大。让我们试试看:

void doSomething(T & t)
{
   // we create "x"
   std::auto_ptr<X> x(new X()) ;    // 1. basic : can throw with new and X constructor
   X * px = x.get() ;               // 2. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 3. basic : can throw

   // we copy the original container to avoid changing it
   T t2(t) ;                        // 4. strong : can throw with T copy-constructor

   // we put "x" in the copied container
   t2.list.push_back(px) ;          // 5. strong : can throw
   x.release() ;                    // 6. nothrow/nofail
   if(std::numeric_limits<int>::max() > t2.integer)  // 7.   nothrow/nofail
      t2.integer += 1 ;                              // 7'.  nothrow/nofail

   // we swap both containers
   t.swap(t2) ;                     // 8. nothrow/nofail
}

我们对操作重新排序，首先创建和设置 X到其正确的值(value)。如果任何操作失败，则 t没有被修改，所以，操作 1 到 3 可以被认为是“强”的:如果有东西抛出， t未修改，且 X不会泄漏，因为它属于智能指针。
然后，我们创建一个拷贝 t2的 t ，并从操作 4 到操作 7 处理此拷贝。如果出现异常， t2被修改，但是， t还是原来的。我们仍然提供强有力的保证。
然后，我们交换 t和 t2 .交换操作不应该在 C++ 中抛出，所以让我们希望你为 T 编写的交换是 nothrow (如果不是，重写它，使其不被抛出)。
所以，如果我们到达函数的末尾，一切都成功了(不需要返回类型)和 t有它的异常(exception)值(value)。如果失败，则 t仍然具有它的原始值(value)。
现在，提供强有力的保证可能会非常昂贵，所以不要努力为你的所有代码提供强有力的保证，但如果你可以不花钱(而且 C++ 内联和其他优化可以使上述所有代码无成本) ，然后去做。功能用户会为此感谢您。
结论
编写异常安全代码需要一些习惯。您需要评估您将使用的每条指令提供的保证，然后您需要评估指令列表提供的保证。
当然，C++ 编译器不会支持保证(在我的代码中，我将保证作为 @warning doxygen 标签提供)，这有点令人难过，但它不应该阻止您尝试编写异常安全的代码。
正常失败与错误
程序员如何保证不失败的函数总是成功的？毕竟，该功能可能有错误。
这是真实的。异常保证应该由无错误代码提供。但是，在任何语言中，调用函数都假定该函数没有错误。没有任何健全的代码可以保护自己免受出现错误的可能性。尽你所能编写代码，然后提供保证，假设它没有错误。如果有错误，请纠正它。
异常是针对异常处理失败的，而不是针对代码错误的。
最后的话
现在，问题是“这值得吗？”。
当然是这样。拥有“nothrow/no-fail”功能，知道该功能不会失败，这是一个巨大的福音。对于“强”函数也可以这样说，它使您能够编写具有事务语义的代码，如数据库，具有提交/回滚功能，提交是代码的正常执行，抛出异常是回滚。
然后，“基本”是您应该提供的最起码的保证。 C++ 是一种非常强大的语言，它的作用域使您能够避免任何资源泄漏(垃圾收集器很难为数据库、连接或文件句柄提供某些东西)。
所以，据我所知，它 是 值得。
编辑 2010-01-29:关于非 throw 交换
nobar 发表了我认为非常相关的评论，因为它是“如何编写异常安全代码”的一部分:

[me] 交换永远不会失败(甚至不要写抛出交换)

[nobar] 这是自定义写的好推荐swap()功能。然而，应该注意的是，std::swap()可能会根据其内部使用的操作失败

默认 std::swap将进行复制和分配，对于某些对象，可能会抛出。因此，默认交换可能会抛出，用于您的类甚至 STL 类。就C++标准而言， vector的交换操作, deque , 和 list不会抛出，而它可以用于 map如果比较仿函数可以进行复制构造(请参阅 The C++ Programming Language, Special Edition, appendix E, E.4.3.Swap)。
查看 vector 交换的 Visual C++ 2008 实现，如果两个 vector 具有相同的分配器(即，正常情况)，则 vector 的交换不会抛出，但如果它们具有不同的分配器，则会生成拷贝。因此，我认为它可能会抛出最后一种情况。
所以，原文仍然成立:永远不要写一个抛出交换，但必须记住诺巴的评论:确保你正在交换的对象有一个非抛出交换。
编辑 2011-11-06:有趣的文章
Dave Abrahams , 谁给了我们 basic/strong/nothrow guarantees ，在一篇文章中描述了他关于使 STL 异常安全的经验:
http://www.boost.org/community/exception_safety.html
看看第 7 点(异常安全的自动化测试)，他依靠自动化单元测试来确保每个案例都经过测试。我想这部分是对问题作者“你能确定吗？”的一个很好的回答。
编辑 2013-05-31:评论来自 dionadar

t.integer += 1; is without the guarantee that overflow will not happen NOT exception safe, and in fact may technically invoke UB! (Signed overflow is UB: C++11 5/4 "If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.") Note that unsigned integer do not overflow, but do their computations in an equivalence class modulo 2^#bits.

Dionadar 指的是以下行，它确实具有未定义的行为。

   t.integer += 1 ;                 // 1. nothrow/nofail

这里的解决方案是在进行加法运算之前验证整数是否已经达到最大值(使用 std::numeric_limits<T>::max() )。
我的错误会出现在“正常失败与错误”部分中，即错误。
它不会使推理无效，也不意味着异常安全代码是无用的，因为不可能实现。
您无法保护自己免受计算机关闭、编译器错误、甚至您的错误或其他错误的影响。你无法达到完美，但你可以尝试尽可能接近。
我根据 Dionadar 的评论更正了代码。