9

Google C++ 编码风格建议不要使用 C++ 异常，我们也不使用它们。对于大多数 STL 库容器，可以忽略异常，因为通常它们表示严重错误并且无论如何都难以处理，因此崩溃是可以接受的。

但是，多线程（std::thread）存在问题，例如两次输入非递归互斥体会引发异常。这种情况并不严重，可以通过等待来处理。

我的问题是：有人知道 Google 使用什么作为线程库吗？是否有任何不使用异常的 C++ 跨平台线程库？

谢谢

4

4 回答 4

13

应该注意的是，谷歌的风格指南并不排除异常的处理，而是抛出异常。即处理问题，但不要因为抛出更多异常而使情况变得更糟。

在重新输入非递归互斥锁的情况下：这显然是程序员的错误，而不是一些意外的晴天霹雳。应该允许异常传播到调用代码，以便可以将其视为错误并进行处理。需要注意的是，Google Test 框架不依赖异常，但它肯定可以捕获并报告异常。

虽然 Google 的风格指南采取了极端的立场，但毫无疑问，在编写可重用库时异常可能会带来很大的问题。例如，我们发现使用 WinCE 6.0 进行开发时，异常会在重新抛出时被分割，并且在 ARM 平台上无法可靠地跨 DLL 边界抛出。此外，捕获异常可能需要几毫秒，因此它们绝对不应该用于需要实时性能的非异常情况（即“预期”错误）。线索真的就在名字里。

于 2013-09-29T03:16:00.760 回答
11

Google 风格指南中的做法可以追溯到上个世纪九十年代初，当时线程是相当奇特的野兽。因此，想知道这种风格和线程如何混合是没有意义的。如果您使用线程等“现代”（21 世纪）技术，则不会使用 Google 的样式指南，反之亦然。

于 2013-09-30T19:17:56.880 回答
9

IIRC 谷歌不使用异常的原因是他们的大部分代码库都不是异常安全的，他们负担不起重写它。

从他们的网站：

从表面上看，使用例外的好处大于成本，尤其是在新项目中。但是，对于现有代码，异常的引入对所有依赖代码都有影响。如果异常可以传播到新项目之外，那么将新项目集成到现有的无异常代码中也会出现问题。由于 Google 现有的大多数 C++ 代码都没有准备好处理异常，因此采用会产生异常的新代码相对困难。

鉴于 Google 现有的代码不是容错的，使用异常的成本比新项目的成本要高一些。转换过程会很慢并且容易出错。我们不认为异常的可用替代方法（例如错误代码和断言）会带来很大的负担。

我们反对使用例外的建议不是基于哲学或道德依据，而是基于实际的依据。因为我们想在 Google 使用我们的开源项目，如果这些项目使用异常就很难做到，所以我们也需要建议不要在 Google 开源项目中使用异常。如果我们不得不从头开始重新做一遍，事情可能会有所不同。

于 2013-09-30T19:29:31.090 回答
1

就个人而言，我更喜欢函数返回码而不是异常。但不管一个人自己的偏好或编码风格如何，重要的是在问题发生的地方抓住问题，不要让它们传播、持续或造成混乱。

我所做的，尤其是在开发过程中，是在检测任何类型的线程中的任何类型的错误时，我让进程自行冻结。在 Linux 上，我发出 SIGSTOP 信号。这样做的好处是，我可以附加一个调试器，并查看整个过程的所有破碎荣耀。

于 2013-09-30T18:35:44.797 回答