在C++中，“不抛出异常”是一个比“正确”更严格的要求。一个函数可以是正确的（在任何有效输入下都能完成其任务），但仍然可能抛出异常。而一个标记为noexcept的函数，则承诺了更强的保证：无论发生什么，这个函数都不会抛出异常。这种承诺对于构建健壮的系统至关重要，特别是在析构函数、移动操作、swap函数以及某些关键路径上。
参考：https://vrhyh.cn/category/yinshi.html
noexcept关键字在C++11中被引入，取代了C++98中不常用的throw()规范。与throw()不同，noexcept不要求编译器检查函数是否真的抛出了异常——违反noexcept承诺的行为是未定义行为，通常会导致程序终止。这种设计反映了C++社区的务实态度：与其试图捕获和处理意外异常，不如直接终止程序，因为继续执行可能导致更严重的数据损坏。
什么情况下应该使用noexcept？最佳实践是只在确实不会抛出异常的函数上使用noexcept。这些函数包括：析构函数（它们应该总是noexcept）、移动构造函数和移动赋值运算符（如果可能的话）、swap函数、简单的getter和setter、以及任何只进行算术运算或指针操作而不分配内存的函数。标记一个会抛出异常的函数为noexcept是一个严重的错误，因为当异常被抛出时，程序会立即终止，而不是通过正常的异常处理流程。
noexcept不仅仅是文档性质的——它对代码生成和标准库的行为有实际影响。标准库通过std::is_nothrow_move_constructible等类型特征来检查类型的noexcept属性。一个经典的例子是std::vector的重新分配：当vector需要增长时，它需要将旧元素移动到新内存。如果移动构造函数是noexcept的，vector会使用移动操作，这通常很快；如果移动构造函数可能抛出异常，vector会回退到拷贝操作，以保证强异常安全（即在分配失败时保持原vector不变）。这意味着一个遗漏的noexcept可能导致严重的性能退化。
参考：https://vrhyh.cn/category/zhongyi.html
noexcept对异常安全级别有直接影响。C++定义了三个异常安全级别：基本保证（基本保证：操作后对象处于有效状态，无资源泄漏）、强保证（操作要么成功要么无变化）和不抛出保证（操作永不失败）。noexcept函数提供了最强的不抛出保证，这种保证对于某些操作是必需的——例如，在析构函数中抛出异常是致命的，因为析构函数在栈展开过程中被调用时，如果再抛出异常，程序会立即终止。
编写不抛出异常的代码需要特定的技巧。一个常见的方法是预先分配：在执行任何可能失败的操作之前，先完成所有可能抛出异常的工作。例如，在实现一个noexcept的赋值运算符时，你可以先构造一个临时副本（这一步可能抛异常），然后与当前对象交换（交换操作应该是noexcept的），最后让临时副本销毁。通过这种“拷贝-交换”惯用法，你可以将抛出异常的风险集中到可以处理的地方，而关键的交换和销毁操作则是安全的。
参考：https://vrhyh.cn/category/zhongyi.html
另一个技巧是使用非抛出版本的库函数。标准库中的许多函数都有不抛出的版本，例如std::copy和std::move在某些条件下可以不抛出。但要注意，这不总是保证的——如果迭代器的拷贝或赋值可能抛异常，那么算法本身也可能抛异常。类似地，算术操作通常不抛异常，但整数溢出在C++中是未定义行为而不是异常，所以你不会从中得到异常安全的保证。
noexcept与RAII的交互尤为重要。考虑一个数据库连接类，其析构函数需要关闭连接。如果关闭连接时网络错误，我们无法抛出异常（因为析构函数中的异常很危险），也无法忽略错误（因为用户可能想知道关闭失败）。一个常见的解决方案是提供一个单独的close函数，用户可以显式调用来处理错误，而析构函数在close失败时要么静默忽略（不推荐），要么记录日志（更合理），要么断言（用于调试）。这种设计将异常安全的负担转移到调用者身上，同时保持了析构函数的noexcept保证。
C++17引入了noexcept作为类型系统的一部分。一个函数指针的类型现在可以包括noexcept信息，这意味着void (f1)() noexcept和void (f2)()是不同的类型。这种变化提高了类型安全性——你不能将一个可能抛异常的函数赋值给一个要求noexcept的函数指针。但这也带来了兼容性问题：许多现有代码假定所有函数指针都是可以抛异常的，升级到C++17后可能需要修改类型声明。
在实际工程中，是否对所有可能标记为noexcept的函数都标记noexcept？答案是否定的。过度使用noexcept可能会导致不必要的代码重复，或者迫使开发者做出不切实际的承诺。更务实的策略是：析构函数、swap函数、移动操作等关键路径应该总是noexcept（除非有充分的理由不这样做）；其他函数如果实现简单且不分配资源，也可以标记noexcept；但对于可能失败的操作（如文件IO、网络通信、内存分配），则不应该标记noexcept。
参考：https://vrhyh.cn
