是否有一个普遍接受的习语来表示 C++ 代码可以抛出异常吗？

Question

我在使用 C++ 代码时遇到过问题，调用者意外地抛出异常。 读取您正在使用的模块的每一行来查看它是否抛出异常以及如果抛出异常，则并不总是可行或不切实际的。

是否存在处理此问题的既定惯用语或“最佳实践”？

我想到了以下内容：

1. 在我们的 doxygen 文档中，我们可以在每个预期抛出异常的函数及其类型中添加注释。

   • 优点：简单。
   • 缺点：容易出现用户错误。

2. 为了安全起见，我们可以在应用程序范围内使用 try/catch(...)。

   • 优点：我们不会再出现任何未捕获的异常。
   • 缺点：异常是在距离抛出很远的地方捕获的。 很难弄清楚该做什么或出了什么问题。

3. 使用异常规范

   • 优点：这是处理此问题的语言认可的方法。
   • 缺点：需要重构问题库才能有效。 在编译时不强制执行，因此违规会变成运行时问题，这正是我试图避免的！

这些方法有什么经验，或者我不知道的任何其他方法？

Answer 1

对标题问题的简短回答 - 表示函数可以抛出的惯用语不是来记录它“这个函数不会抛出”。 也就是说，默认情况下一切都可以抛出。

C++ 不是 Java，并且没有编译器检查的异常。 C++ 中没有任何东西可以让编译器告诉您您的代码声称它不会抛出，但调用了可能会抛出的东西。 所以你不能完全避免这是一个运行时问题。 静态分析工具可能会有所帮助，但不确定。

如果您只关心 MSVC，则可以考虑在不抛出异常的函数上使用空异常规范或 __declspec(nothrot)，并在不抛出异常的函数上使用 throw(...)的功能。 这不会导致代码效率低下，因为 MSVC 不会发出代码来检查声明为 nothrow 的函数实际上不会抛出。 GCC 可以使用 -fno-enforce-eh-specs 执行相同的操作，请检查您的编译器文档。 然后一切都将被自动记录。

选项 2，应用程序范围的 try-catch 并不是真正的“为了安全”，这只是因为你认为你可以用异常做一些更有用的事情（比如打印出一些东西并干净地退出），而不仅仅是让 C++ 运行时调用 <代码>终止。 如果您在编写代码时假设某件事不会抛出，而实际上确实发生了，那么您可能在其中任何一个实际发生之前就已经未定义，例如，如果析构函数对一致状态做出了错误的假设。

我通常会做（1）的变体：对于每个函数记录它提供的异常保证 - 不抛出、强、弱或无。 最后一个是一个错误。 第一个很有价值但很少见，并且只有交换函数和析构函数才严格需要良好的编码。 是的，它可能会出现用户错误，但任何带有异常的 C++ 编码方式都会出现用户错误。 然后，如果它可以帮助您执行（1），那么还可以执行（2）和/或（3）。

Symbian 有一个预标准的 C++ 方言，有一个称为“leave”的机制，在某些方面类似于异常。 Symbian 中的约定是任何可能离开的函数都必须以 L 结尾命名：CreateL、ConnectL 等。平均而言，这会减少用户错误，因为您可以更容易地看到您是否正在调用可能会离开的东西。 正如您所料，讨厌它的人就像讨厌应用程序匈牙利表示法一样，如果几乎所有功能都离开它，它就不再有用。 正如您所期望的，如果您确实编写了一个名称中没有 L 的函数，那么在您找出问题之前，它可能会在调试器中等待很长时间，因为您的假设使您远离了实际的错误。

Answer 2

解决问题的惯用方法不是指示您的代码可以抛出异常，而是在您的对象中实现异常安全。 该标准定义了对象应实现的几个异常保证：

• 无抛出保证：函数将永远不会抛出异常
• 强大的异常安全保证：如果抛出异常，对象将保持其初始状态。
• 基本的异常安全保证：如果抛出异常，对象将保持有效状态。

当然，该标准记录了每个标准库类的异常安全级别。

这确实是 C++ 中处理异常的方法。 不要标记哪些代码可以或不能抛出异常，而是使用 RAII 来确保对象得到清理，并考虑在 RAII 对象中实现适当级别的异常安全，这样它们就能够在以下情况下生存而无需特殊处理：抛出异常。

只有当异常允许您的对象处于无效状态时，异常才会真正引起问题。 那绝对不应该发生。 您的对象应该始终至少实现基本保证。 （实现提供适当级别的异常安全性的容器类是一项具有启发性的 C++ 练习；））

至于文档，当您能够确定函数可能抛出的某些异常时，通过无论如何，请随意记录它。 但一般来说，当没有指定其他内容时，就假定函数可能会抛出异常。 空抛出规范有时用于记录函数何时从不抛出。 如果不存在，则假设该函数可能会抛出异常。

Answer 3

坦率地说，几乎任何 C++ 函数都可能引发异常。 您不必太担心记录这一点，而是通过使用 RAII 等习惯用法来确保代码异常安全。

Answer 4

我用的是1和2。

关于1：
您无法避免或阻止用户错误。 如果您认识没有将 doxygen 正确写入纸浆的开发人员，您可以击败他。 但你无法避免或阻止用户错误，所以放弃偏执吧。 如果用户犯了错误，那是他犯的，而不是你犯的。

关于2：
C# 内置了一种捕获未处理异常的方法。 所以这并不是一件“坏事”，尽管我同意它有味道。 有时，崩溃比不一致运行更好，但我做了一个练习，记录任何未处理的异常，然后崩溃。 这允许人们向我发送日志，以便我可以检查堆栈跟踪并找出问题。 这样，每次修正后，崩溃的发生就会越来越少。

Answer 5

文档似乎是我所知道的唯一合理的方法。

关于异常规范，这是 Herb Sutter 撰写的一篇关于该主题的旧文章 (2002) http://www.ddj .com/cpp/184401544 它讨论了为什么该语言的这一特性不能为我们提供编译时安全性，并最终得出结论：

所以这似乎是最好的
我们作为一个社区学到的建议
截至今天：

道德#1：永远不要编写异常
规格。

道德#2：除非可能是空的
一个，但如果我是你，我什至会避免
那个。

Answer 6

C++ 在 c++11 之前定义了抛出规范。 请参阅此问题。 根据我过去的经验，微软编译器会忽略 C++ 抛出规范。 “检查异常”的整个概念是有争议的，尤其是在 Java 领域。 许多开发人员认为这是一次失败的实验。

Answer 7

使用 doxygen 文档来描述您的方法。 当您使用它们时，您需要检查此文档以了解它们的参数是什么以及它们抛出哪些异常。

编写单元测试以在抛出异常的情况下测试您的代码。

Answer 8

1. 记录异常安全的级别功能保证。 正如史蒂夫·杰索普（Steve Jessop）在回答中指出的那样，有很多层次。 理想情况下，如果它们全部记录在接口中，或者至少有必要的最低限度：a）从不抛出或b）可能抛出

   阅读 亚伯拉罕异常安全保证，由 赫伯·萨特。

2. 我强烈怀疑它在大型代码库中是否实用。 对于远离抛出和很难弄清楚该做什么的问题，一个好的规则是只在你想要处理异常的地方捕获，否则就让它处理冒泡。 一旦异常出现就立即捕获并消除它们并不是一个好主意，仅仅因为……它们是异常，所以你觉得你必须对其做点什么。 在复杂的系统中，最好有日志机制，这样更容易跟踪问题。

3. 别这么做。 阅读 Herb Sutter 的异常规范的实用视角及相关文章。

Answer 9

您应该始终期待异常并处理它们。 不幸的是，计算机没有自动方式为您进行尽职调查。

Answer 10

编号
唯一常见的事情是表明你不要扔任何东西。
然后您还应该手动确保没有异常可以真正逃脱您的方法/函数。 注意：如果异常确实逃逸了该方法，则应用程序将被终止。

#include <stdexcept>

class MyException: public std::exception
{
    public:
    ~MyException() throw() {}
     char* what() const throw()
     {
        try
        {
            // Do Stuff that may throw
            return "HI";
        }
        // Exceptions must not escape this method
        // So catch everything.
        catch(...)
        {
           return "Bad Stuff HAppening Cant Make Exception Message.";
        }
     }
};

Answer 11

在 C++ 中，有一种方法可以指定函数可以抛出哪些异常。 Stroustrup 书中的一个示例

void f(int a) throw (x2, x3);

指定 f 只能抛出 x2 或 x3 类型或派生类型的异常。 使用此语法，您可以轻松查看函数声明，以了解合法允许抛出哪些异常，并进行相应的编码。