谷歌的C++编码风格中有无异常规则。那么多线程呢？

Question

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

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

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

谢谢

- Isso

---

你是否因好奇而问，对于你的情况，有没有不使用异常的理由？你不是盲目遵循谷歌的编程风格指南吧？因为该指南是针对为谷歌编写软件的程序员而制定的（我知道公司里有许多人憎恶这个政策），并不是一般建议。 - Benjamin Lindley

谷歌的C++风格有些过时，你为什么要遵循它？和其他任何东西一样，异常可以被滥用，但它们并不是坏的，简单地禁止它们是有些可悲的。 - Cory Nelson

同时，按照标准，在持有std::mutex锁的情况下再次进入该锁是不被定义的行为——最好的情况是你可能会得到一个异常。最糟糕的情况下，你可能会陷入死锁。在这里发生的异常可以归类为关键错误。 - Cory Nelson

@CoryNelson：关于在同一线程中多次进入相同互斥量，对于递归互斥量（muteces？）来说，它完全是明确定义并且受标准支持的（正如OP所暗示的那样）。 - yzt

OP并没有暗示，他明确表示他正在使用一个非递归互斥锁。 - Cory Nelson

Answer 1

应注意，Google的样式指南并不排除处理异常，而是避免抛出异常。也就是说，要解决问题，但不要通过抛出更多的异常使问题变得更糟。

在重新进入非递归互斥时，这显然是程序员的错误，而不是某种意外的情况。异常应该被允许向上传播到调用代码，以便将其视为错误并加以处理。值得注意的是，Google Test框架不依赖于异常，但它可以捕获并报告异常。

虽然Google的样式指南持有极端立场，但毫无疑问，在编写可重复使用的库时，异常可能会带来很大问题。例如，在开发WinCE 6.0时，我们发现在重新抛出时异常被切片，而在ARM平台上不能可靠地跨DLL边界抛出。此外，捕获异常可能需要几毫秒的时间，因此在需要实时性能的非异常情况(即“预期”的错误)中绝对不应该使用异常。名称已经提示了这一点。

- sheddenizen

Answer 2

Google的样式指南实践可以追溯到上个世纪90年代初，当时线程是相当陌生的。因此，想知道这种风格和线程如何混合没有意义。如果您使用21世纪的“现代”技术（例如线程），则不使用Google的样式指南，反之亦然。

- MSalters

---

那么应该使用哪种风格指南？ - meshy

嗯，这里总有一点主观性，但是C++编程规范要好得多。 - MSalters

Answer 3

据我所知，谷歌不使用异常的原因在于他们的很多代码库都不支持异常，而且他们无法承担重写代码的成本。

从他们的网站上可以看到：

使用异常的好处明显大于代价，尤其是对于新项目来说。然而，对于现有的代码，引入异常会影响所有相关的代码。如果异常可以传播到新项目以外的代码中，那么将新项目整合到没有异常处理的现有代码中就会出现问题。由于谷歌现有的大多数C++代码都没有准备好处理异常，因此采用生成异常的新代码相对困难。

考虑到谷歌现有代码并不容忍异常，使用异常的代价比在新项目中高一些。转换过程会很慢且容易出错。我们认为，与使用异常相比，其他可用的替代方案（例如错误代码和断言）不会带来明显的负担。

我们反对使用异常并不是基于哲学或道德观点，而是实际考虑。因为我们希望在谷歌开源项目中使用我们的开源项目，在这种情况下如果那些项目使用异常，我们需要建议不要在谷歌开源项目中使用异常。如果我们必须从头开始做它，情况可能会有所不同。

- Dan

Answer 4

个人而言，我更喜欢使用函数返回代码而不是异常。但无论一个人的个人偏好或编码风格如何，重要的是在出现问题时捕获它们，不要让它们传播、持久化或造成混乱。

特别是在开发过程中，我会在检测到任何类型的错误时使进程自动冻结。在Linux上，我会发出SIGSTOP信号。这样做的好处是我可以使用调试器附加并查看整个进程及其所有错误的细节。

- bazza

---

实际上，在开发过程中使用SIGSTOP停止自己的做法似乎很有用。并不总是有调试器在手边。对此点赞。 - Jonas Schäfer

@JonasWielicki，是的，这是一个方便的技巧。另一个技巧是让程序在出错时自动生成核心转储并杀死自己。从一个保持重新启动的脚本运行它。你最终会得到一组核心文件，每个文件都冻结在出错点，你可以稍后进行分析。这比程序无法处理神秘异常而死亡要好得多，并且不必在调试器下运行它（对于长时间运行的程序可能不是选项）。对于那些难以找到且很少发生的错误非常方便。此外，您可以同时运行许多程序，更快地找到错误。 - bazza