1. 项目概述为什么我们需要关注noexcept在C的世界里异常处理一直是个让人又爱又恨的话题。爱它是因为它提供了一种结构化的错误处理机制能将错误处理代码与正常业务逻辑分离恨它是因为它带来的运行时开销和复杂性尤其是在性能敏感的系统中。如果你写过一些追求极致性能的代码或者维护过大型项目肯定对异常带来的不确定性深有体会——一个函数会不会抛异常如果会它抛什么这直接影响了我们如何设计资源管理、数据结构和算法。C11引入的noexcept关键字以及C17对其类型系统地位的强化就是为了解决这种不确定性。它不是一个简单的“保证不抛异常”的声明而是一套与编译器优化、移动语义、容器行为深度绑定的语言机制。我见过太多项目要么完全忽略noexcept导致错失大量优化机会要么滥用noexcept结果在运行时意外触发std::terminate让程序崩溃得莫名其妙。这篇文章我就结合自己十多年踩坑填坑的经验带你深入理解noexcept。我们不止看语法更要看它如何影响代码生成、如何与STL容器互动、如何在编译期和运行期发挥作用。我会分享一些实际项目中的使用策略、常见的误区和那些手册上不会写的调试技巧。无论你是正在优化现有代码库还是设计新的高性能组件理解并善用noexcept都是提升代码质量和运行效率的关键一步。2.noexcept的核心机制与C17的关键变革要玩转noexcept首先得搞清楚它的两种形态和它在C标准演进中的角色变化。很多开发者只知道noexcept能声明函数不抛异常但对其背后的原理和C17带来的根本性改变一知半解。2.1noexcept的两种形态说明符与运算符noexcept在C中有两个身份它们长得像但作用完全不同初学者很容易混淆。noexcept说明符 (Noexcept Specifier)这是用在函数声明中的用来指定该函数是否可能抛出异常。它的基本形式有两种void func() noexcept;// 无条件声明不抛异常等价于noexcept(true)void func() noexcept(expr);// 条件性声明当expr在编译期求值为true时不抛异常为false时可能抛异常。这里的expr必须是一个常量表达式。一个经典用法是结合noexcept运算符来定义模板函数的行为templatetypename T void swap(T a, T b) noexcept(noexcept(a.swap(b))) { a.swap(b); }内层的noexcept(a.swap(b))是一个运算符它在编译期检查表达式a.swap(b)是否可能抛出异常。外层的noexcept(...)是说明符根据内层运算符的结果来决定swap函数本身的异常规范。这种“套娃”写法是编写泛型、异常安全代码的利器。noexcept运算符 (Noexcept Operator)这是一个一元运算符用于在编译期判断一个表达式是否被声明为不抛出任何异常。它返回一个bool类型的常量表达式。bool can_throw noexcept(func()); // 如果func()可能抛异常则为false static_assert(noexcept(std::move(obj)), Move should be noexcept for optimization);这个运算符是编译期元编程和静态断言的好帮手它允许我们根据类型的属性比如移动操作是否noexcept来做出不同的编译期决策。注意noexcept运算符判断的是“表达式是否被声明为noexcept”而不是“表达式在实际运行时会不会抛出异常”。即使一个函数内部有throw语句但被声明为noexcept运算符对其求值结果依然是true。运行时抛异常会触发std::terminate。2.2 C17的核心变革noexcept成为函数类型的一部分这是C17关于noexcept最重大、也是最容易被忽视的变革。在C11/14中noexcept说明符不是函数类型的一部分。这意味着什么看个例子// C14 及之前 void (*func_ptr)() noexcept some_func; // 错误noexcept不是类型的一部分无法用于指针声明 void (*func_ptr)() some_func; // 正确指针类型不包含异常规范。在早期标准中异常规范包括noexcept和已废弃的throw()更像是一种附加属性不影响函数的底层类型。这导致了一些尴尬你不能直接用带有noexcept的函数地址去初始化一个普通的函数指针反之亦然需要经过转换。C17彻底改变了这一点。noexcept说明符以及noexcept(true)或noexcept(false)正式成为了函数类型的一部分。这个改变带来了几个直接影响函数重载void f() noexcept;和void f();现在是两个不同的函数类型不能构成重载。编译器会报重复定义错误因为它们签名相同但异常规范不同。指针和引用指向noexcept函数的指针和指向可能抛出异常函数的指针现在是不同的类型。它们之间的转换需要遵循更严格的规则通常是从noexcept到可能抛出的隐式转换是允许的反之则不行。类型系统一致性这使得类型系统更加完备和一致。一个函数的“调用契约”现在明确包含了它是否会抛出异常这对于模板元编程、std::function包装等场景至关重要。这个变革的深层意义在于它让“异常安全保证”从一种模糊的“文档说明”升级为编译器可以严格检查和利用的“类型信息”。编译器能基于此做更多激进的优化而开发者也能在接口设计上表达更精确的契约。2.3noexcept与已废弃的throw()有何不同很多从C98/03过渡来的开发者会问noexcept和以前的throw()动态异常规范有什么区别简单说noexcept是throw()的现代化、零开销替代品。throw()(动态异常规范C17弃用C20移除)它要求函数只能抛出括号内列出的异常类型空列表表示不抛异常。如果函数抛出了未列出的异常运行时会调用std::unexpected()这通常会导致程序终止。关键在于为了实现这个运行时检查编译器通常需要在函数调用前后插入额外的“栈展开”代码unwinding code即使函数从不抛异常这部分开销也可能存在。noexcept(C11引入)它只是一个布尔标志。noexcept或noexcept(true)向编译器承诺“我不会抛异常”。如果这个承诺被打破即函数内部抛出了异常程序会直接调用std::terminate()终止不保证栈会展开。正因为没有复杂的运行时检查契约编译器可以假设noexcept函数永远不会抛异常从而进行大量优化比如省略不必要的栈展开保护代码甚至内联更多函数调用。从C17开始throw()被明确定义为noexcept(true)的等价物这意味着它们具有相同的语义和优化潜力。但你应该始终使用noexcept因为它是现代、明确的语法。3. 实战解析noexcept如何影响代码生成与STL行为理解了原理我们来看看noexcept在实际编码中到底能带来什么好处。它的价值主要体现在编译期优化和标准库的智能行为上。3.1 编译器优化基于noexcept的代码生成策略当编译器看到一个函数被标记为noexcept它会基于一个关键假设进行优化这个函数的控制流永远不会因为异常而跳出。这解锁了几种优化可能性省略栈展开代码 (Stack Unwinding Code)在可能抛异常的函数中编译器需要生成额外的代码来跟踪哪些对象需要被析构即栈展开。对于noexcept函数编译器可以安全地假设不需要这些簿记信息从而生成更小、更快的代码。更激进的内联 (Inlining)内联一个可能抛异常的函数是复杂的因为需要处理内联后的异常传播路径。对于noexcept函数这个顾虑消失了编译器更愿意将其内联尤其是小型函数。移动语义的强化 (Enhanced Move Semantics)这是noexcept影响最直接、最显著的领域。标准库中的许多操作如std::vector::resize,std::swap, 算法重排在需要转移对象时会在“移动”和“拷贝”之间做选择。它们优先使用移动操作因为移动通常更高效。但是如果移动构造函数或移动赋值运算符不是noexcept的这些库操作为了提供“强异常安全保证”操作失败时状态不变可能会退而求其次使用拷贝操作因为拷贝通常不会抛异常假设类型设计合理。举个例子std::vector在重新分配内存push_back导致容量不足时需要将旧元素移动到新内存。如果元素的移动构造函数是noexcept的vector会直接移动效率极高。如果不是vector可能会选择拷贝以确保如果在移动中途抛出异常旧容器中的元素仍然完好。这个行为可以通过std::move_if_noexcept这个工具函数来观察和验证。3.2 STL容器的“智能”选择std::move_if_noexcept的幕后工作std::move_if_noexcept是理解noexcept如何影响STL的绝佳窗口。它是一个条件转换器根据类型的移动构造函数是否被声明为noexcept来决定返回左值引用还是右值引用。它的典型实现逻辑如下templatetypename T typename std::conditional !std::is_nothrow_move_constructibleT::value std::is_copy_constructibleT::value, const T, // 如果不能noexcept移动但可拷贝返回常量左值引用促使拷贝 T // 否则返回右值引用促使移动 ::type move_if_noexcept(T x) noexcept;std::is_nothrow_move_constructibleT::value这个类型特质就是通过noexcept运算符在编译期检测出来的。实战场景假设你有一个自定义类MyType。class MyType { public: MyType(MyType other) noexcept { ... } // 移动构造声明为noexcept // ... 其他成员 }; std::vectorMyType vec; // ... 填充vec vec.push_back(MyType{}); // 当vector扩容时因为移动构造是noexcept会直接移动现有元素。如果移除noexceptclass MyType { public: MyType(MyType other) { ... } // 可能抛异常 // ... 其他成员 }; std::vectorMyType vec; // ... 填充vec vec.push_back(MyType{}); // vector扩容时由于移动可能抛异常为了强异常安全可能会选择拷贝现有元素性能下降。这个性能差异在元素数量多或元素本身拷贝成本高时是巨大的。我曾在一次性能剖析中发现某个关键数据结构的push_back操作比预期慢了一个数量级追查到底就是因为忘记给移动构造函数加noexcept导致std::vector在后台默默进行了拷贝。3.3 特殊成员函数的隐式noexcept规则对于编译器自动生成的或使用 default声明的特殊成员函数析构函数、构造函数、赋值运算符它们的noexcept状态有一套隐式规则。了解这些规则对于编写异常安全的类至关重要。析构函数 (Destructors)在C11之后所有析构函数都隐式地是noexcept的无论你是否显式写出。即使你写了~MyClass() noexcept(false)这也是唯一可以显式声明为可能抛异常的情况但极其不推荐因为如果析构函数在栈展开过程中抛异常程序会直接终止。默认和拷贝/移动操作编译器隐式生成的默认构造函数、拷贝构造函数、拷贝赋值运算符、移动构造函数、移动赋值运算符它们的noexcept状态是“条件性”的。简单来说如果生成该函数需要调用的所有操作基类或成员的对应操作都是noexcept的那么生成的函数就是noexcept的否则就是可能抛异常的 (noexcept(false))。例如struct Base { Base() noexcept default; Base(Base) noexcept default; }; struct Member { Member() noexcept(false) {} // 可能抛异常 Member(Member) noexcept default; }; struct MyClass : Base { Member m; // 编译器隐式生成的 MyClass() 是 noexcept(false) 的因为 Member::Member() 可能抛异常。 // 编译器隐式生成的 MyClass(MyClass) 是 noexcept 的因为 Base::Base(Base) 和 Member::Member(Member) 都是 noexcept。 };如果你依赖编译器的隐式生成务必清楚这些隐式生成的函数是否满足你的noexcept期望。在需要强异常保证的类中最好显式地用 default并加上noexcept说明符让意图更清晰也便于编译器检查和优化。class ResourceHolder { public: ResourceHolder(ResourceHolder other) noexcept default; // 明确要求移动不抛异常 ResourceHolder operator(ResourceHolder other) noexcept default; ~ResourceHolder() noexcept default; // 显式声明虽然隐式也是但更清晰 // ... 其他成员 };4. 高级应用与元编程编译期利用noexceptnoexcept不仅是运行时的契约更是编译期元编程的有力工具。通过noexcept运算符和相关的类型特质我们可以在模板和泛型代码中做出更智能的决策。4.1 使用noexcept运算符进行条件编译noexcept运算符的结果是一个布尔常量表达式这意味着它可以用于if constexpr(C17) 或SFINAE技术在编译期选择不同的代码路径。场景实现一个通用的safe_move辅助函数我们希望实现一个函数在移动操作是noexcept时使用移动否则使用拷贝以在泛型代码中自动选择最优策略。templatetypename T std::remove_reference_tT safe_move(T t) noexcept { if constexpr (std::is_nothrow_move_constructible_vstd::remove_reference_tT || !std::is_copy_constructible_vstd::remove_reference_tT) { // 情况1移动是noexcept的或者根本不可拷贝则移动。 return std::move(t); } else { // 情况2移动可能抛异常但可以拷贝则拷贝。 return t; // 这里返回的是拷贝构造的结果 } }这个函数模仿了std::move_if_noexcept的部分逻辑但返回的是一个新对象而不是引用。它在泛型库代码中很有用当你需要转移一个对象但又必须保证基础异常安全时。结合SFINAE在C17之前常用SFINAE来根据noexcept选择重载。templatetypename T auto move_or_copy(T t) - typename std::enable_if std::is_nothrow_move_constructibleT::value || !std::is_copy_constructibleT::value, T ::type { return std::move(t); } templatetypename T auto move_or_copy(T t) - typename std::enable_if !std::is_nothrow_move_constructibleT::value std::is_copy_constructibleT::value, T ::type { return t; // 拷贝 }4.2 类型特质库中的noexcept查询工具type_traits头文件提供了一系列与noexcept相关的类型特质它们是编译期查询的标准化工具std::is_nothrow_default_constructibleTstd::is_nothrow_copy_constructibleTstd::is_nothrow_move_constructibleTstd::is_nothrow_copy_assignableTstd::is_nothrow_move_assignableTstd::is_nothrow_destructibleTstd::is_nothrow_swappableT/std::is_nothrow_swappable_withT, U(C17)这些特质都以_v后缀提供变量模板版本如std::is_nothrow_move_constructible_vT使用起来非常方便。它们是编写异常安全泛型代码的基石。应用示例为自定义容器实现异常安全的reserve假设你在实现一个简单的动态数组类SimpleVector。在reserve函数中你需要将旧元素移动到新内存。为了提供强异常保证你可以利用这些特质templatetypename T class SimpleVector { T* data_; size_t size_, capacity_; public: void reserve(size_t new_cap) { if (new_cap capacity_) return; T* new_data static_castT*(::operator new(new_cap * sizeof(T))); size_t i 0; try { for (; i size_; i) { // 关键决策点根据移动是否nothrow选择构造方式 if constexpr (std::is_nothrow_move_constructible_vT) { new (new_data i) T(std::move(data_[i])); // 移动构造 } else { new (new_data i) T(data_[i]); // 拷贝构造 } } } catch (...) { // 如果构造失败析构已构造的部分释放内存原数据保持不变 for (size_t j 0; j i; j) { (new_data j)-~T(); } ::operator delete(new_data); throw; // 重新抛出异常保持强异常保证 } // 所有元素转移成功销毁旧元素替换指针 for (size_t j 0; j size_; j) { data_[j].~T(); } ::operator delete(data_); data_ new_data; capacity_ new_cap; } };这个实现虽然简化但展示了核心思想利用noexcept信息在编译期选择最优且安全的策略。4.3 条件性noexcept规范在模板中的应用对于函数模板我们经常希望其异常规范依赖于模板参数。这就是条件性noexcept说明符noexcept(expr)大显身手的地方。经典案例自定义swap函数为自定义类提供swap特化是常见的优化手段。一个良好的swap应该是noexcept的因为它通常只涉及指针交换或简单的移动操作不应该失败。namespace my_namespace { class Widget { int* data; size_t size; public: friend void swap(Widget a, Widget b) noexcept { using std::swap; swap(a.data, b.data); // 内置类型交换是noexcept的 swap(a.size, b.size); // 同上 } }; }对于模板类我们可以让swap的noexcept依赖于成员swap或移动操作是否noexcepttemplatetypename T class Container { T* elem; public: friend void swap(Container a, Container b) noexcept(noexcept(swap(a.elem, b.elem))) { swap(a.elem, b.elem); } };这里内层的noexcept(swap(...))是运算符检查交换指针的操作是否noexcept对于原始指针它是noexcept的。外层的noexcept(...)是说明符使得Container::swap的异常规范与指针交换操作一致。为移动构造函数和移动赋值运算符添加条件性noexcept这是提升类在STL容器中性能的关键。你应该为你自定义的、资源管理类的移动操作添加noexcept并且这个noexcept应该基于成员和基类移动操作的noexcept状态。class MyResourceHolder { std::unique_ptrResource ptr; std::vectorint data; public: // 移动构造函数当所有成员的移动构造都是noexcept时本函数才是noexcept MyResourceHolder(MyResourceHolder other) noexcept( std::is_nothrow_move_constructible_vdecltype(ptr) std::is_nothrow_move_constructible_vdecltype(data) ) : ptr(std::move(other.ptr)), data(std::move(other.data)) {} // 移动赋值运算符同理 MyResourceHolder operator(MyResourceHolder other) noexcept( std::is_nothrow_move_assignable_vdecltype(ptr) std::is_nothrow_move_assignable_vdecltype(data) ) { ptr std::move(other.ptr); data std::move(other.data); return *this; } };这样声明后MyResourceHolder的移动操作是否noexcept将自动、正确地由其成员决定。当它被放入std::vector时就能享受高效的移动而非拷贝。5. 工程实践何时使用、如何测试与常见陷阱了解了所有机制后最关键的是如何在项目中正确应用。滥用noexcept比不用更危险。5.1 何时应该使用noexcept决策指南给函数加noexcept是一个承诺。遵循以下原则可以帮你做出正确决定析构函数永远不要声明为noexcept(false)。最好显式写上noexcept或保持默认隐式noexcept。移动操作构造/赋值这是noexcept应用的重中之重。对于管理资源的类如持有指针、文件句柄、网络连接移动操作通常只是交换或转移资源所有权不分配新资源因此应该是noexcept的。这能确保你的类在STL容器中获得最佳性能。如果移动操作因为某些原因如必须分配辅助内存可能失败请仔细权衡或者考虑让移动操作不可用 delete强制使用拷贝。交换函数 (swap)自定义的swap应该尽可能做到noexcept因为它通常只进行指针交换或简单的移动操作。默认构造函数、拷贝操作如果它们只是简单地对成员进行初始化或拷贝并且所有成员的对应操作都是noexcept的那么将它们声明为noexcept是安全的并且可能带来微小的优化。但这不是强制的因为拷贝操作通常不涉及资源转移在容器重新分配时不是关键路径。简单、无副作用的Getter/Setter例如int getValue() const noexcept { return value_; }。这类函数显然不会抛异常加上noexcept既正确又能给编译器提示。关键性能路径上的小函数如果经过 profiling 发现某个小函数是热点并且你确信它不会抛异常加上noexcept可能促使编译器将其内联。标准库算法和函数对象的调用运算符如果你自定义的函数对象要在标准库算法中使用并且其调用运算符不会抛异常标记为noexcept可能让算法内部做一些优化。何时避免使用noexcept函数内部调用了可能抛异常的函数如new可能抛std::bad_alloc、文件操作、动态转换dynamic_cast等并且你没有捕获这些异常。函数逻辑复杂你无法百分之百确定其所有执行路径都不会抛异常。记住noexcept的承诺一旦被违反程序会立刻终止。对于虚函数要特别小心。如果基类的虚函数是noexcept那么所有派生类的重写版本也必须隐式或显式是noexcept的否则编译失败。这限制了派生类的实现灵活性。5.2 测试noexcept的正确性与影响如何验证你加的noexcept是否正确以及它是否真的带来了优化静态检查使用static_assert结合类型特质来验证你的类是否满足期望的noexcept属性。static_assert(std::is_nothrow_move_constructible_vMyClass, MyClass should have a noexcept move constructor for optimal performance in containers.); static_assert(std::is_nothrow_move_assignable_vMyClass, MyClass should have a noexcept move assignment operator.);在单元测试中可以使用noexcept运算符来断言某个表达式不应该抛异常。TEST(MyClassTest, MoveIsNoexcept) { MyClass obj1, obj2; EXPECT_TRUE(noexcept(obj1 std::move(obj2))); // 使用Google Test或类似框架 }性能测试 最直观的方法是观察std::vector等容器的行为。你可以编写一个简单的性能对比测试#include vector #include chrono #include iostream class MovableNoexcept { public: MovableNoexcept() default; MovableNoexcept(MovableNoexcept) noexcept default; // noexcept移动 // ... 模拟一些资源 }; class MovableThrow { public: MovableThrow() default; MovableThrow(MovableThrow) {} // 可能抛异常的移动 // ... 模拟一些资源 }; templatetypename T void test_performance() { std::vectorT vec; vec.reserve(1000); // 预分配避免测试中的重复分配干扰 auto start std::chrono::high_resolution_clock::now(); for (int i 0; i 100000; i) { vec.push_back(T{}); // 反复插入触发内部的移动/拷贝逻辑 if (vec.size() vec.capacity()) { vec.clear(); // 清空下一轮push_back又会触发重新分配和元素转移 } } auto end std::chrono::high_resolution_clock::now(); auto duration std::chrono::duration_caststd::chrono::milliseconds(end - start); std::cout Time: duration.count() ms\n; } int main() { std::cout Testing MovableNoexcept (noexcept move):\n; test_performanceMovableNoexcept(); std::cout \nTesting MovableThrow (potentially throwing move):\n; test_performanceMovableThrow(); }在我的测试环境中MovableNoexcept版本通常会比MovableThrow版本快数倍这直观地展示了noexcept移动对容器性能的巨大利好。5.3 常见陷阱与避坑指南过度承诺 (Over-promising)这是最大的坑。给一个实际上可能抛异常的函数加上noexcept等于埋下了一颗定时炸弹。一旦异常抛出std::terminate会被调用程序立即崩溃几乎没有调试信息。黄金法则当你不能百分百确定时不要加noexcept。对于复杂函数保守一点更好。忽略继承体系中的虚函数如果基类的虚函数是noexcept所有派生类的重写版本也必须保持noexcept或更严格即也是noexcept。如果派生类版本可能抛异常你就需要重新设计基类接口或者将异常处理下放到派生类内部捕获。误以为noexcept影响函数签名C17前在C17前noexcept不是函数类型的一部分所以不能用于区分重载。在C17后它可以但要谨慎使用因为这可能导致令人困惑的API。在函数指针转换中犯错C17后从noexcept函数指针到可能抛异常的函数指针的转换是隐式的因为这是一种放宽的转换但反过来则需要显式转换并且可能不安全。void (*p1)() noexcept nullptr; void (*p2)() p1; // C17起OK隐式转换 // p1 p2; // 错误不能将可能抛异常的指针赋给noexcept指针 p1 static_castvoid(*)() noexcept(p2); // 需要显式转换但风险自担条件性noexcept中的表达式求值时机noexcept(expr)中的expr只在需要时才被实例化类似于SFINAE上下文。这通常不是问题但如果你在expr中使用了未实例化的模板可能会遇到令人惊讶的编译错误。确保expr中的类型和表达式在求值时是良定义的。6. 深入排查当noexcept导致程序终止时怎么办尽管我们小心翼翼但有时还是可能意外违反noexcept承诺导致程序调用std::terminate。崩溃堆栈通常只显示terminate被调用很难定位到底是哪个noexcept函数抛了异常。调试技巧设置std::terminate处理器你可以通过std::set_terminate设置一个自定义的终止处理器。在这个处理器中尝试打印堆栈信息或记录日志。虽然标准不保证在调用terminate_handler时堆栈还未展开但在许多实现中此时还能获取到一些有用的信息。#include iostream #include exception #include cstdlib void my_terminate_handler() { std::cerr std::terminate called! Possibly an exception escaped a noexcept function.\n; // 在这里可以尝试打印堆栈需要平台相关支持如Linux的backtrace std::abort(); // 通常还是终止程序 } int main() { std::set_terminate(my_terminate_handler); // ... your code }使用调试器在GDB或LLDB中你可以在std::terminate处设置断点。当程序中断时检查调用堆栈找到导致terminate的最近用户函数那很可能就是违反noexcept承诺的函数。代码审查与静态分析对于关键路径仔细审查所有标记为noexcept的函数实现确保它们没有直接或间接通过调用的函数抛出异常的可能。使用编译器的警告选项如GCC/Clang的-Wnoexcept或-Wnoexcept-type可以帮助检测一些潜在问题。静态分析工具也可能有所帮助。增量测试对于复杂的noexcept函数进行充分的单元测试模拟各种边界条件和异常情况确保异常确实被内部捕获和处理不会逃逸出去。一个真实的排查案例我曾遇到一个服务程序偶尔会神秘崩溃日志只显示terminate called without an active exception。最终通过核心转储文件和在terminate处设断点发现问题出在一个标记为noexcept的日志清理函数中。该函数调用了第三方库的一个文件删除接口我们错误地认为该接口不会失败或失败时仅返回错误码。但实际上在极端磁盘错误下该第三方函数会抛出一个系统异常。解决方案是要么移除noexcept如果允许日志清理失败要么在函数内部用try...catch(...)捕获所有异常并转换为错误码或日志记录。归根结底noexcept是一把双刃剑。它能为性能带来显著提升尤其是与移动语义和STL容器配合时。但它也要求开发者对代码的异常安全有更深刻的理解和更严格的把控。在现代C项目中有策略地、准确地使用noexcept是编写高质量、高性能、可维护代码的重要标志。我的经验是从移动操作和析构函数开始逐步扩展到那些你确信无异常的关键路径函数同时辅以严格的测试和代码审查就能安全地享受noexcept带来的红利。