Google C++编码风格建议不要C++例外，我们也不使用它们。对于大多数 STL 库容器，可以忽略异常，因为通常它们指示严重错误并且无论如何都难以处理，因此崩溃是可以接受的。
但是，多线程(std：：thread(存在问题，例如，输入非递归互斥锁两次会引发异常。这种情况并不严重，可以通过等待来处理。
我的问题是：有人知道谷歌使用什么作为线程库吗？是否有任何不使用异常的C++跨平台线程库？
谢谢
应该注意的是，谷歌的风格指南并不排除处理异常，而是抛出例外。 即处理问题，但不要通过抛出更多异常来使其变得更糟。
在重新输入非递归互斥锁的情况下：这显然是程序员的错误，而不是一些意想不到的螺栓。应允许异常传播到调用代码，以便可以将其视为错误并进行处理。应该注意的是，Google 测试框架不依赖于异常，但它当然可以捕获并报告它们。
虽然Google的风格指南采取了极端的立场，但毫无疑问，在编写可重用库时，异常可能会产生很大的问题。例如，我们发现使用 WinCE 6.0 进行开发时，异常在重新抛出时被切片，并且在 ARM 平台上无法可靠地跨 DLL 边界抛出。此外，捕获异常可能需要几毫秒，因此它们绝对不应该用于需要实时性能的非特殊情况(即"预期"错误(。线索真的在名字里。
谷歌风格指南中的做法可以追溯到上世纪九十年代初，当时线程是相当奇特的野兽。因此，想知道这种风格和线程将如何混合是没有意义的。如果您使用线程等"现代"(21 世纪(技术，则不会使用 Google 的风格指南，反之亦然。
IIRC Google不使用异常的原因是，他们的许多代码库都不是异常安全的，他们负担不起重写它的费用。
从他们的网站：
从表面上看，使用异常的好处大于成本，尤其是在新项目中。但是，对于现有代码，引入异常会对所有相关代码产生影响。如果异常可以传播到新项目之外，那么将新项目集成到现有的无异常代码中也会出现问题。由于Google的大多数现有C++代码都没有准备好处理异常，因此采用生成异常的新代码相对困难。
鉴于Google的现有代码不具有异常容忍能力，因此使用异常的成本略高于新项目的成本。转换过程会很慢且容易出错。我们认为，异常的可用替代方法(如错误代码和断言(不会带来重大负担。
我们反对使用例外的建议不是基于哲学或道德基础，而是基于实际基础。因为我们想在 Google 使用我们的开源项目，如果这些项目使用例外，很难做到这一点，所以我们也需要建议不要在 Google 开源项目中出现例外。如果我们必须从头开始，情况可能会有所不同。
就个人而言，我更喜欢函数返回代码而不是异常。但无论自己的偏好或编码风格如何，重要的是在问题发生的地方发现问题，不要让它们传播、持续或造成混乱。
我所做的，特别是在开发过程中，是检测任何类型的线程中的任何错误，我让进程冻结自己。在Linux上，我发出SIGSTOP信号。这样做的好处是，我可以附加调试器，并查看整个过程的所有破碎荣耀。