假设你有一个通常永远不会失败的功能,例如：
std::string convert_integer_to_string(int x);
在市政当局,这将是noexcept的候选人.但是,最可能涉及的实现涉及动态内存管理,因此在使用new运算符分配内存时总是会抛出std::bad_alloc.
是否建议将该函数注释为noexcept？
从实际的角度来看,以合理的方式处理内存不足的情况是极其困难的.大多数程序只假设有足够的可用内存.调用std :: terminate,因为如果noexcept函数抛出std :: bad_alloc会发生这种情况,在这种情况下似乎是合理的.
对我来说,noexcept是某种形式的文档.这是一个承诺,你(或优化器)可以安全地假设这个函数永远不会抛出.如果您正在编写一个不关心内存不足情况的应用程序,那么它仍然是一个有效的假设.
我想最安全的建议是如果可以抛出std :: bad_alloc异常,就永远不要使用noexcept.另一方面,我想知道无论如何使用noexcept都有好处,假设你不关心内存不足的情况(即,如果std :: terminate是好的).
解决方法
如果函数可以出于某种原因抛出异常,即使它是std :: bad_alloc,也不应该将其声明为noexcept.相对较少的函数实际上不能抛出异常,它实际上也很重要. noexcept函数的主要需求是允许在异常的情况下检测可用的错误恢复选项：例如,std :: vector< T,A>假设移动结构不投掷,可以在插入对象时使用移动构造.如果移动构造可以抛出,则在实现强异常安全操作时,移动对象不能用于恢复异常.因此,如果移动构造对于类型T可能失败,则std :: vector< T,A>的实例化.不能移动对象但需要复制它们.
特别是,不要将noexcept用作虚假文档：如果函数实际可以抛出则违反合同.如果发生此违规行为,系统会对某些已定义的行为做出反应,这并不意味着您应该利用它. …虽然简单的程序可能无法恢复并且只是在内存不足时死亡,但真正的程序可能至少需要存储足够的状态来恢复它们在死亡时留下的混乱,即,它对于任何功能都是不可接受的做出关于杀死程序的决定(当然,除非记录该功能的意图).
