问题标签 [exception-specification]

如果有怎么办？

我知道如何为成员提供异常规范，例如

所以method只有投掷SOMEException。如果我想确保SOMEClassthrow SOMEExceptionfor的子类pure_method，是否可以添加异常规范？这种方法是否可行，还是我需要更多地了解异常和抽象方法以找出为什么可以（不能）完成？

我是一位经验丰富的非托管 C++ 开发人员，不熟悉 C++\CLI。

为什么托管 C++ 不允许异常规范？

示例链接

指定我的方法抛出的异常的最佳实践是什么？

我在使用 C++ 代码时遇到了一些问题，调用者出乎意料地抛出了异常。阅读您正在使用的模块的每一行以查看它是否抛出异常以及如果是，那么是什么类型的异常并不总是可能或实际的。

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

我想到了以下几点：

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

   • 优点：简单。
   • 缺点：受用户错误的影响。

2. 为了安全，我们可以有一个应用程序范围try/catch(...)。

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

3. 使用异常规范

   • 优点：这是处理这个问题的语言认可的方式。
   • 缺点：需要重构问题库以使其有效。在编译时未强制执行，因此违规会变成运行时问题，这是我要避免的！

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

我正在处理严重依赖于语言标准中描述的异常规范行为的旧代码。即，在违反下述形式的异常规范时调用 std::unexpected()。

Nothrow 规范确实保证不会抛出，但是throw(T)规范预计会被设计和……所违反，因为标准期望同样多，并提供了一种处理它的机制。

其原因与设计人员决定使用 EH 作为除异常处理之外的错误处理机制（由其自己的错误类层次结构控制）有关。EH 中呈现的成语与他们的需求密切相关，他们采取了最省力的方式。考虑到系统的规模和复杂性，这至少是我的看法，而且对我来说并不是特别令人震惊。

然而，我现在的任务是包含新的和不相关的功能，并且由于与 8.0 中引入的异常规范相关的标准存在偏差，因此代码在 VC++ 9.0 下的行为与预期不同。（参考：微软）

我试图找到一种强制标准行为的方法。希望编译器提供后备。但是没有。

我是否运气不好，需要更改在 350,000 行代码上运行的正确编写的符合标准的代码，并具有完全开发的错误处理类层次结构？或者你能想出一种方法来帮助我强制 std::unexpected() 行为吗？

编辑： 我提供了一些背景信息。有问题的系统是一个学年日历生成器，为一所学校服务，分布在 4,000 多名学生中，我不确定其中的一些数字，6 个年级和约 190 个班级，外加 12 个虚拟（远程教学）类。MINGW 与 VC++ 8.0 或 9.0 以外的任何编译器一样，都是不可能的。这是由于有关为该国教育系统服务的软件的规定。

代码所需的更改正是为了适应虚拟类的引入，这些虚拟类具有用于日历生成的截然不同的模式。然后我碰到了这个问题。该软件在日历生成过程的几个部分大量使用异常机制，作为通过意外（）映射（保存和恢复）和 bad_exception 映射来控制工作流的一种手段，这些映射都不能在 VC++ 下工作。就纯粹个人而言，我发现该机制实际上非常优雅，即使完全不常见。但我离题了。

考虑以下代码：

编译时，它说派生类 B 与 A 相比具有更宽松的抛出说明符。这有什么重要性？如果我们尝试交换它们的异常规范，使得 A::f() 抛出 int 和 double 而 B::f() 只抛出 int，则不会出现错误。

我知道这个特性在 C++0x 中会被弃用，但对于我这个新手来说，拥有它似乎是个好主意。谁能向我解释为什么不是一个好主意？

我最近得到了一个别人实现的dll。我必须在我的应用程序中使用它。在他们的类的头文件中，他们有函数声明

现在当我编译它时收到警告，

忽略 C++ 异常规范，除非指示函数不是 _declspec(nothrow)

我阅读了MSDN - 文档但无法清楚地理解它。另外，我不想仅仅因为它出现就禁用警告。我想知道我做错了什么而不是禁用它。

我认为我的函数，说 myfunc()从 dll访问它func1()没有那个异常规范列表。因此，我也尝试在我的函数中使用相应的异常规范列表，

但我仍然收到警告。该警告的全部内容是什么以及如何摆脱它？我在 Windows XP 中使用 Qt 4.5。

C++ 标准规定了以下关于具有异常规范的虚函数：

如果虚函数具有异常规范，则在任何派生类中覆盖该虚函数的任何函数的所有声明（包括定义）都应仅允许基类虚函数的异常规范（C + +03 §15.4/3)。

因此，以下格式不正确：

(1) 此规则是否适用于析构函数？也就是说，下面的格式是否正确？

(2) 该规则如何应用于隐式声明的析构函数？也就是说，下面的格式是否正确？

虽然在一般情况下永远不应该编写异常规范，但这个问题具有实际意义，因为std::exception析构函数是虚拟的并且具有空的异常规范。

由于不允许从析构函数中抛出异常是一种很好的做法，因此为了简化任何示例，我们假设析构函数要么允许所有异常（即，它没有异常规范），要么不允许异常（即也就是说，它有一个空的异常规范）。

最近一位同事问我对在 C++ 代码中使用异常规范的看法，我能够挖掘出 Herb Sutter 的这篇文章：A Pragmatic Look at Exception Specifications。与 Herb Sutter 的大多数文章一样，这篇文章是一本教育读物，但简短的回答是“不要那样做”。

在总结中，他提到了一首题为“实施前的夜晚”的诗，其中，标准委员会实际上在最后一刻屈服于用户的要求，添加了一个功能，结果发现当它做了什么是要求，它并没有真正做到他们想要的。是的，异常规范符合该法案。正如他所说，“当时这个功能似乎是个好主意，这正是一些人所要求的。” 如果这还不够，他然后访问“出口”，结果类似的悲惨结果。

所以问题是这样的：如果你不想流泪，C++ 的什么“特性”被证明是坏的，不应该被使用。这可能是主观争吵的牺牲品，但我希望人们会引用一个特定的体验，即部署该功能只是为了引起可衡量的问题。更好的是像 Sutter（或任何深入参与该标准的人）这样的领导者引用文章，警告人们不要使用某个功能。

我有一个异常类如下：

在 GCC 4.4 下使用 -Wall -std=c++0x 编译时

错误：'virtual const char* InvalidPathException::what() const' 的更宽松的抛出说明符

错误：覆盖 'virtual const char* std::exception::what() const throw ()'

也非常正确，因为我正在覆盖确实具有异常说明符std::exception的 's方法。但正如人们经常被告知的那样，我们不应该使用异常说明符。据我了解，它们在 C++11 中已被弃用，但显然尚未在带有 -std=c++0x 的 GCC 中。what()throw()

所以我现在对最好的方法感兴趣。在我正在开发的代码中，我确实关心性能，因此担心经常提到的开销throw()，但实际上这种开销如此严重吗？我是否认为我只会在what()实际调用时遭受它，这只会在抛出这样的异常之后（同样对于从 std::exception 继承的其他方法都具有throw()说明符）？

或者，有没有办法解决 GCC 给出的这个错误？