C++ 添加'noexcept（false）`对代码有任何好处吗？

最近，在我的代码中，我一直在显式地编写

noexcept（false）

函数，我知道这些函数会抛出异常，主要是针对阅读代码的人。但是，我想知道这是否会影响代码的行为或编译器解释代码的方式。这有什么区别吗

---

注：我知道析构函数隐式表示noexcept，您必须指定

noexcept（false）

来改变这一点，我想知道其他函数。

没有异常说明符并显式声明

noexcept（false）

是等效的，请参见§15.4/12：

一个没有异常规范或异常规范形式为

noexcept（常量表达式）

的函数，其中常量表达式产生

false

允许所有异常

因此，编译器在考虑异常时不应区分它们

---

更重要的是，您无需在函数中附加

noexcept（false）

。作为C++开发人员，你应该假定默认情况下每个函数都会抛出（这就是标准采取这种立场的原因），所以你不需要通过写出来添加新的信息；这对每个人来说都是浪费时间

相反，一定要用

noexcept

标记函数肯定不会抛出的特殊情况，并用

noexcept（condition）

标记函数根据某些条件可能抛出的情况

如果您的函数有意成为某些异常的来源，请将其写入您的文档。

在他的书中，有以下代码片段（第130页）：

示例19-1的正确答案要简单得多：

// Example 19-4: The right solution
//
T::~T() /* throw() */
{
 // ... code that won't throw ...
}

示例19-4演示了如何做出设计决策，而不是胡言乱语

请注意，

throw（）

不会抛出任何异常规范 这只是一个评论这是我选择遵循的风格，在某种程度上 因为事实证明，异常规范提供的信息要少得多 利益大于价值。您是否决定实际编写规范是一个品味问题

（强调矿山）

>，我觉得我必须指出C++中的一个主要的安全异常代码似乎是反对添加编译器使用异常规则的概念（但是仍然把它留给程序员理解的代码）。

---

只是觉得这可能是有趣的信息…

throw（）

和

noexcept（true）

正是因为这个原因而不同。我认为将构造函数和移动任务移到<>代码>除（真），并认为任何其他东西都是bug是至关重要的。是这样吗？他提到，

throw（）

是不好的，因为它会做奇怪的事情。在你发布的链接中，他似乎对将

nothrow（true）

应用于整个标准库毫无保留。请注意，在C++11中，析构函数默认为

noexcept（true）

。如果您想覆盖它，您必须添加

noexcept（false）

。然而，这几乎总是一个坏主意。（我敢说这总是个坏主意；我只是用“几乎”来避险，以防我没有足够的想象力。）大量的代码，包括标准库，假设析构函数总是成功的，如果清理失败，以故障可恢复的方式编写代码是非常困难的。在许多情况下，这是不可能的（例如静态初始化或多个类成员）*/表示您没有意外忘记在接口中添加

noexcept

。我希望有一种方法来标记一个函数，使它可以抛出，即使编译器可以通过过程间分析确定它不可能抛出。@kchoi:如果编译器正在确定这一点，为什么重要？调试嵌入式系统的总线错误、非调用异常（当前的有限制？）等等。