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