void MyFunction(int i) throw();
它只是告诉编译器该函数不会抛出任何异常。
它不能确保函数什么都不抛出，对吗？
那么 throw() 有什么用
它是多余的吗？为什么提出这个想法？
【问题讨论】：
标签： c++
首先，当编译器工作正常时，它被强制执行——但在运行时，而不是编译时。具有空异常规范的函数不会抛出异常。如果发生某些事情会创建一个从它逃逸的异常，则会调用unexpected()，而后者（反过来）调用abort。您可以使用set_unexpected 更改调用的内容，但该函数所允许做的只是在中止程序之前添加额外的“东西”（例如清理）——它无法返回到原始执行路径。
也就是说，至少有一个主要编译器 (VC++) 解析异常规范，但不强制执行它们，尽管它可以使用空异常规范来稍微改进优化。在这种情况下，未遵循的异常规范可能/确实会导致未定义的行为，而不是必然中止程序。
【讨论】：
它不能确保函数什么都不抛出，对吗？
你快到了。这是一个异常规范。这意味着作为实施者，您向您的客户保证这段代码不会引发异常。但是，这不会阻止 MyFunction 中的某些函数抛出，如果您不处理它们，它们会冒泡并以您不希望的方式导致您/客户的程序。这甚至不意味着你不能在里面有一个throw 表达式。
最好避免这样的规范，除非你绝对确定你的代码永远不会抛出——除了非常基本的功能之外，这有点困难。参见标准swap、指针分配等。
它是多余的吗？为什么提出这个想法？
不完全是。如果使用得当，它可以帮助编译器进行优化。请参阅this 文章。 This 文章解释了不投掷井背后的历史。
进一步挖掘，我发现了来自 Boost 文档的 this 优秀文章。必读。阅读异常保证部分。
【讨论】：
throw() 的一致实现，虽然允许更好地优化 caller，但给 callee 带来了巨大的负担，这足以抵消调用者获得的任何好处；所以最后是净亏损。也就是说，你的第一个链接是一个专门描述 VC++ 的博客，它没有以一致的方式实现throw()（而不是在抛出时强制函数终止，它只是说它是 U.B. 如果它发生），这让它优化调用者而不为被调用者付出代价。您关于nothrow 的第二个链接与此无关。
throw() 的实现并没有带来那么大的负担。相当于：try { function_body(); } catch(...) { (*unexpected)(); }。大多数当前的编译器可以输入try 块而很少或没有开销，并且在这种情况下应该能够执行相同的操作。也就是说，真正的用途不是优化——只是如果没有至少一些保证不会抛出（任何东西，永远）的原语，几乎不可能使任何异常安全。
try 块内联函数。
正如您所说，它只是告诉编译器该函数不会引发任何异常。
当编译器预期可能的异常时，它通常必须以某种特定形式生成代码，这会降低效率。它还可能必须生成一些额外的“家庭”代码，以便在抛出异常时以及是否抛出异常时进行处理。
当你告诉编译器这个函数从不抛出任何东西时，它会让编译器更容易识别所有这些额外的异常相关开销完全没有必要的情况，从而帮助编译器生成更高效的代码。
请注意，如果在运行时您实际上尝试从使用throw() 规范声明的函数中抛出一些东西，则不允许异常离开该函数。相反，将调用一个所谓的意外异常处理程序，默认情况下它将终止程序。因此，从这个意义上说，实际上强制 throw() 函数不会抛出任何东西。
附：由于异常规范主要影响程序的运行时行为，因此通常它们可能没有任何编译时影响。然而，这个特定的异常规范 - 空的 throw() - 实际上在 编译时 被一些编译器识别，并且确实导致生成更高效的代码。有些人（包括我）认为空异常规范是唯一真正值得在实际代码中使用的规范。
【讨论】：
throw()，编译器也必须生成异常代码来执行你所说的运行时执行。
throw() 函数的外部 生成高效代码。另一方面，执行代码是函数的内部问题。
说实话，现实世界中的异常规范并没有像原始设计者所设想的那样有用。此外，C++ 运行时检查异常规范和 Java 编译时检查异常规范之间的差异也造成了很多问题。
目前异常规范的例外规范有：
主要问题是，如果您有一个带有 throw 规范的方法。然后它使用下面的更改，现在抛出新类型的异常，代码没有警告或问题。但是在运行时，如果发生异常（不在 throw 规范中的新异常），那么您的代码将终止（）。对我来说，终止是最后的手段，绝不应该在格式良好的程序中发生
【讨论】：