C++异常机制深度解析：性能、安全与工程实践的权衡

1. 项目概述：C++异常机制为何成为争议焦点？

最近在几个技术社区和论坛里，看到不少关于“大厂禁用C++异常”的讨论，甚至有些标题直接用了“封杀”、“拉黑”这样的字眼。作为一个在C++领域摸爬滚打了十几年的老码农，我第一反应是：这事儿又被拿出来炒冷饭了。但仔细一想，这个话题之所以能反复被提起，恰恰说明它触及了C++开发中一个深层次、且没有标准答案的核心矛盾——性能、安全性与开发效率的权衡。

C++异常处理（Exception Handling）自诞生之日起，就伴随着巨大的争议。它不像Java或C#中的异常那样被广泛接受和依赖。在C++的世界里，异常更像是一把双刃剑，用好了能优雅地处理错误，让代码逻辑更清晰；用不好，或者在不合适的场景下使用，它就可能成为性能的“黑洞”、内存泄漏的“元凶”，甚至是导致程序崩溃的“定时炸弹”。所谓的“大厂封杀”，本质上并不是对语言特性的全盘否定，而是一种在特定工程约束（如高性能服务器、嵌入式系统、游戏引擎）下，基于成本收益分析后做出的集体性工程决策。这种决策背后，是无数个深夜加班排查core dump、优化性能热点后，用血泪换来的经验教训。

这篇文章，我们就来彻底拆解一下C++异常这个“危险操作”。我们不谈空泛的理论，就从实际的工程角度出发，看看异常机制到底在哪些环节容易“翻车”，为什么在一些对性能和确定性要求极高的场景下，开发者们会选择“惹不起，躲得起”的策略，以及如果你不得不面对一个禁用异常的项目，有哪些成熟、可靠的替代方案。无论你是正在学习C++的新手，还是已经工作多年、但对异常机制心存疑虑的老手，希望这篇深度剖析能给你带来一些实实在在的启发。

2. 异常机制的工作原理与潜在成本

要理解为什么异常会被“嫌弃”，首先得搞清楚它到底是怎么工作的。很多教科书和入门教程对异常的介绍停留在 try 、 catch 、 throw 的语法层面，但这远远不够。异常真正的“重量”，隐藏在语法糖的背后。

2.1 栈展开（Stack Unwinding）的隐藏开销

当你 throw 一个异常时，程序的控制流会立刻中断，并开始沿着调用栈向上回溯，寻找匹配的 catch 块。这个过程就是栈展开。听起来很简单，但编译器为了支持这个功能，在背后做了大量工作。

首先，编译器必须为每个可能抛出异常的函数生成额外的“栈展开信息”（unwind information或 .eh_frame 段）。这些信息记录了每个函数中，当异常发生时，哪些局部对象需要调用析构函数，以及如何安全地跳转到上一级调用栈。这些信息会显著增加二进制文件的大小，尤其是在大量使用RAII（Resource Acquisition Is Initialization）模式、拥有许多局部对象的代码中。

其次，栈展开过程本身并非“免费午餐”。它需要运行时库（如 libstdc++ 或 libc++ ）的参与来查找和匹配异常处理代码。这个过程涉及到查表、跳转，其时间复杂度并非O(1)。在深度嵌套的函数调用中抛出一个异常，其开销可能远超一次普通的函数返回。

注意 ：这里有个常见的误解，认为“不抛出异常就没开销”。实际上，只要编译时开启了异常支持（ -fexceptions ），即使你的代码里一个 throw 都没有，编译器仍然会生成栈展开信息，二进制体积和一定的间接开销依然存在。这就是为什么一些极致性能项目会直接编译时关闭异常（ -fno-exceptions ）。

2.2 异常安全（Exception Safety）的编程负担

异常引入的最大挑战之一，是它彻底改变了我们对代码执行路径的假设。在没有异常的世界里，函数的执行流程是相对线性和可预测的。但异常可能在任何时候、从任何地方（包括标准库调用、第三方库）抛出，将控制流转移到不可预知的地方。

这就引出了“异常安全”的概念。一个异常安全的函数需要保证，即使有异常抛出，也不会破坏程序的不变量、不会导致资源泄漏。Herb Sutter将其分为几个级别：

1. 不提供保证（No guarantee） ：异常可能导致资源泄漏、数据破坏。这是最糟糕的情况。
2. 基本保证（Basic guarantee） ：如果异常抛出，程序状态仍然有效（无资源泄漏，所有对象仍可析构），但具体状态不可预测。
3. 强保证（Strong guarantee） ：如果异常抛出，程序状态完全回滚到函数调用前的样子。这通常通过“拷贝-交换”（copy-and-swap）惯用法实现。
4. 不抛异常保证（Nothrow guarantee） ：函数承诺绝不抛出任何异常。

为了实现强异常安全，代码往往需要变得更加复杂。你需要仔细考虑每个操作是否可能失败，并使用RAII来管理所有资源（内存、文件句柄、锁等），确保在异常发生时析构函数能被正确调用以释放资源。一个经典的“坑”是在修改容器或复杂数据结构时，如果操作中途抛出异常，可能会让数据结构处于“半更新”的无效状态。

// 一个非异常安全的例子：向一个自定义容器插入元素
void MyVector::push_back(const T& value) {
    if (size_ == capacity_) {
        // 重新分配内存
        T* new_data = static_cast<T*>(operator new(capacity_ * 2 * sizeof(T)));
        // 问题1：如果下面的拷贝构造抛出异常，new_data内存泄漏！
        for (size_t i = 0; i < size_; ++i) {
            new (new_data + i) T(data_[i]); // placement new，可能抛出
        }
        // 问题2：如果析构旧元素抛出异常？灾难。
        for (size_t i = 0; i < size_; ++i) {
            data_[i].~T();
        }
        operator delete(data_);
        data_ = new_data;
        capacity_ *= 2;
    }
    // 在data_[size_]位置构造新元素，也可能抛出
    new (data_ + size_) T(value);
    ++size_;
}

上面这个简陋的 push_back 实现充满了异常安全问题。在真实项目中，写出完全异常安全的代码需要极高的专注度和经验，这无疑增加了开发和维护的心智负担与时间成本。

2.3 对代码可读性与调试的影响

异常处理改变了错误传播的方式。错误不再通过返回值显式传递，而是通过隐式的控制流跳转。这虽然可以让主逻辑代码更干净，但也使得在阅读代码时，很难一眼看出哪些函数调用可能失败，以及失败后的处理逻辑在哪里。

在调试时，这个问题更加突出。当一个程序在某个点崩溃时，如果是因为一个未被捕获的异常（ std::terminate ），调用栈可能已经被部分展开，丢失了异常最初抛出的完整上下文信息。相比之下，通过错误码返回，在调试器中查看返回值或全局错误状态往往更直接。

此外，异常的类型系统也可能成为负担。你需要决定抛出什么类型的异常（标准异常、自定义异常）、在哪个层级捕获、是否需要重新抛出（ throw; ）。不恰当的异常类型设计会导致过宽或过窄的 catch 块，要么捕获了不该处理的错误，要么让真正的错误溜走。

3. 大厂“封杀”异常的真实场景与核心考量

所谓“封杀”，通常体现在项目的编码规范或编译器 flags 中。例如，Google 的 C++ 风格指南在很长一段时间内都明确禁止使用异常，其理由非常具有代表性。我们来剖析一下这些考量背后的工程现实。

3.1 性能确定性的终极追求

在一些对延迟极其敏感的场景，比如高频交易系统、游戏渲染循环、嵌入式实时操作系统（RTOS）的核心逻辑，性能的“可预测性”比“平均速度快”更重要。异常破坏了这种可预测性。

• 时间不确定性 ：抛出和捕获异常的时间开销是难以预测的，它取决于调用栈的深度、异常对象的构造复杂度等。在需要严格保证响应时间的软实时系统中，这种不确定性是不可接受的。
• 二进制大小与缓存影响 ：如前所述，异常支持会增加二进制体积。在内存受限的嵌入式设备上，每一KB都弥足珍贵。更大的代码段也可能对CPU指令缓存（I-Cache）和数据缓存（D-Cache）更不友好，从而影响性能。
• 零开销抽象原则 ：C++哲学强调“你不需要为你不需要的东西付费”。对于这些场景，异常处理带来的开销正是他们“不需要”且“不愿付费”的。

因此，这些项目通常在编译时直接使用 -fno-exceptions 标志彻底禁用异常。这迫使所有代码（包括你使用的库，如果它们想被集成）都必须在不依赖异常的前提下工作。

3.2 遗留代码库与ABI兼容性

许多大型C++代码库拥有超过十年甚至二十年的历史。在异常机制被广泛理解和应用之前，这些代码已经基于错误码、断言（ assert ）、或简单的进程终止（ abort ）建立了一套完整的错误处理范式。

引入异常会带来巨大的迁移成本和风险：

1. 全面重构 ：需要审查几乎每一行代码，评估其异常安全性，并可能进行重写。这对于百万、千万行级别的代码库是不现实的。
2. 混合错误处理 ：如果部分模块用异常，部分用错误码，两者边界的交互会异常（双关）复杂和容易出错。你需要决定是在边界处进行转换，还是让两种模式并存，后者会大大增加认知负担。
3. ABI（应用程序二进制接口）问题 ：异常处理与编译器的实现紧密相关。不同编译器（GCC vs Clang）、甚至同一编译器的不同版本，其异常实现（Itanium C++ ABI, SJLJ, DWARF等）可能不兼容。这在动态链接库（DLL/SO）的交互中可能导致难以调试的崩溃。

所以，对于这些大厂来说，维持现有稳定、统一的错误处理策略，其收益远大于引入异常可能带来的那点代码简洁性。

3.3 对第三方库的强制约束

一个项目禁用异常，意味着所有它链接的第三方库也不能使用异常。这带来了两个问题：

1. 库的选择受限 ：许多现代C++库（包括Boost的某些部分）严重依赖异常来报告错误。禁用异常等于将这些库拒之门外，或者需要寻找其特殊的“无异常”构建版本（如果存在的话）。
2. 标准库的“阉割” ：C++标准库大量使用异常。 std::vector::at() 会抛 std::out_of_range ， std::bad_alloc 在内存分配失败时抛出。禁用异常后，这些函数的行为是未定义的（通常会导致程序终止）。因此，项目必须建立一套严格的标准库使用规范，例如禁止使用 at() ，用 reserve() 来避免 push_back 时的内存分配失败等，这又增加了规则负担。

4. 禁用异常后的生存指南：主流替代方案剖析

如果异常被禁用，我们该如何处理错误？业界已经形成了几套成熟的模式，各有其适用场景。

4.1 返回错误码（Error Codes）

这是最传统、最直接的方式。函数通过返回值（或出参）表明成功或失败。

enum class ErrorCode {
    kSuccess = 0,
    kFileNotFound,
    kPermissionDenied,
    kInvalidArgument,
    kOutOfMemory,
    // ...
};

ErrorCode OpenFile(const std::string& path, FileHandle& out_handle);
ErrorCode ReadData(FileHandle handle, void* buffer, size_t size, size_t* bytes_read);

优点 ：

• 极其明确 ：调用者必须显式检查错误，控制流清晰。
• 零开销 ：就是一次整数比较，性能可预测。
• 调试友好 ：错误发生点就在函数返回后，上下文完整。

缺点 ：

• 代码臃肿 ：每个可能出错的调用后都需要 if (err != kSuccess) { ... } ，干扰主逻辑。
• 容易忽略 ：程序员可能忘记检查错误码。
• 错误信息有限 ：一个整数错误码往往难以携带详细的错误上下文（哪个文件、哪一行数据有问题）。

实操心得 ：为了减少“忘记检查”的问题，有些项目会使用“必须检查”（ [[nodiscard]] ）属性来修饰返回错误码的函数，或者定义一些宏/工具函数来简化检查逻辑。对于错误信息，可以配套一个 GetLastErrorString() 之类的函数来获取详细描述。

4.2 使用 std::expected 或 tl::expected (C++23/第三方库)

这是近年来更受推崇的现代化方案，它融合了返回值与异常的一些优点。核心思想是让函数返回一个“可能包含值，也可能包含错误”的联合体。

// 使用第三方库如 tl::expected 或 C++23 的 std::expected
tl::expected<std::string, ErrorCode> ReadConfigFile(const std::string& path) {
    std::ifstream file(path);
    if (!file) {
        return tl::unexpected(ErrorCode::kFileNotFound); // 返回错误
    }
    std::string content;
    // ... 读取内容
    if (/* 解析失败 */) {
        return tl::unexpected(ErrorCode::kInvalidFormat); // 返回错误
    }
    return content; // 返回成功值
}

// 调用方
auto result = ReadConfigFile("app.conf");
if (!result) { // 检查是否有错误
    std::cerr << "Error: " << ErrorToString(result.error()) << std::endl;
    return;
}
std::string config = *result; // 解引用获取值

优点 ：

• 强类型安全 ：成功值和错误类型在编译期确定，无法被忽略（必须解包才能获取值）。
• API清晰 ：函数签名直接表明了可能的错误类型。
• 组合性好 ：可以通过 and_then 、 transform 等操作符进行链式调用，类似函数式编程中的 Monad 。

缺点 ：

• 需要C++17或更高版本 （对于第三方实现），或等待C++23普及。
• 学习成本 ：对于不熟悉函数式编程概念的开发者有一定门槛。
• 错误传播仍需手动 ：虽然比原始错误码优雅，但依然需要手动检查并传递错误。

4.3 断言（Assertions）与契约（Contracts）

断言用于捕获在程序正确运行时绝不应该发生的逻辑错误，通常与调试构建（Debug Build）相关联。

void ProcessBuffer(void* data, size_t size) {
    assert(data != nullptr && "Data pointer cannot be null!"); // 防御性编程
    assert(size > 0 && "Size must be positive!");
    // ... 处理逻辑
}

优点 ：

• 在开发阶段极有价值 ：能快速暴露程序员的假设错误。
• 发布版本零开销 ：通常通过 NDEBUG 宏，断言在Release版中被完全移除。

缺点 ：

• 不是错误处理机制 ：断言用于处理编程错误（bug），而非预期的运行时错误（如文件不存在、网络断开）。后者需要用错误码或其它机制。
• 行为激进 ：断言失败通常直接终止程序，不适合需要优雅降级或恢复的场合。

C++20曾试图引入“契约”（Contracts）特性（ [[expects]] , [[ensures]] , [[assert]] ），提供更丰富的编译期和运行时检查，但该特性已被推迟。目前断言仍是主要工具。

4.4 自定义终止与日志策略

对于一些非关键性的错误，或者在不允许失败的单次初始化场景中，直接记录日志并终止程序或当前操作，也是一种简单粗暴但有效的策略。这通常与监控和告警系统结合。

bool InitializeCriticalSubsystem() {
    if (!LoadEssentialDLL()) {
        LOG(FATAL) << "Failed to load essential DLL. System cannot start.";
        // LOG(FATAL) 可能会调用 std::abort 或触发一个断点
        return false; // 实际上不会执行到这里
    }
    // ... 其他初始化
    return true;
}

这种方式的核心是：承认某些错误无法或不应在运行时恢复，快速失败（Fail Fast）并留下清晰的诊断信息，总比让程序带着隐藏的错误继续运行（导致后续更诡异的问题）要好。

5. 实战决策：何时用异常？何时不用？

经过上面的分析，我们可以得出一些更具体的指导原则，而不是简单地“封杀”或“拥抱”。

5.1 考虑使用异常的场景

1. 上层应用逻辑、工具软件 ：这些程序对性能的极致要求不高，更关注开发效率和代码清晰度。异常可以避免错误码的层层传递，让业务逻辑更突出。
2. 库的接口设计（面向广大用户） ：如果你在编写一个通用库，且无法预测用户的使用场景（他们可能启用也可能禁用异常），那么提供异常接口通常是更友好的。因为用户可以选择捕获异常，也可以选择编译时关闭异常（此时标准库行为可能变化，但你的库接口仍在）。同时， 强烈建议提供无异常的替代API （如 std::filesystem 同时提供抛异常的 copy 和不抛异常的 copy 带 std::error_code 参数的重载）。
3. 构造函数和运算符 ：构造函数没有返回值，报告失败的唯一优雅方式就是抛出异常（如 std::bad_alloc ）。类似地，重载运算符（如 operator[] ）也很难通过返回值报告错误。
4. 不可恢复的错误（逻辑错误） ：例如 std::logic_error 的子类，表示程序员的错误。虽然断言也用于此，但异常允许在更高层级进行统一的日志记录或用户提示。

5.2 建议避免使用异常的场景

1. 实时系统与性能敏感核心 ：如游戏引擎的主循环、音频处理回调、高频交易策略。这里需要确定性的执行时间。
2. 嵌入式与资源受限环境 ：内存和闪存空间宝贵，异常机制的开销（代码体积、运行时支持）可能无法承受。
3. 已有大型遗留代码库 ：如果现有代码完全基于错误码，引入异常的成本和风险极高，收益却不明显。
4. 跨语言/跨二进制边界 ：在C++模块与C、Python、Lua等语言交互时，异常无法安全地跨越边界。必须设计C接口在边界处捕获并转换异常为错误码。
5. 析构函数 ：析构函数绝对不应该抛出异常！如果析构函数中调用的操作可能失败，必须吞掉异常或采取其他措施。因为当栈展开时，如果析构函数也抛出异常，程序会直接调用 std::terminate 。

5.3 混合策略与工程实践

在实际项目中，完全纯粹的策略很少见，更常见的是混合策略：

• 核心底层库禁用异常 ：提供基于错误码或 expected 的API。编译时使用 -fno-exceptions 。
• 上层业务逻辑使用异常 ：在底层库的边界，通过薄薄的包装层将错误码转换为异常（或反之），隔离两种错误处理模式。例如：

  // 底层库API
  ErrorCode LowLevelFunc(int arg, Result& out);
  
  // 给上层业务使用的包装
  Result HighLevelFunc(int arg) {
      Result out;
      ErrorCode err = LowLevelFunc(arg, out);
      if (err != ErrorCode::kSuccess) {
          throw MyAppException("LowLevelFunc failed", err); // 转换
      }
      return out;
  }
  

• 明确团队的约定并写入规范 ：无论选择哪种策略，最重要的是团队内部达成一致，并形成明确的编码规范。规范中应详细说明：在什么模块用什么方式、如何转换错误、禁止哪些操作（如禁止在析构函数抛异常）、如何使用标准库等。

6. 常见陷阱与排查技巧实录

即使决定使用异常，在实际编码和调试中也会遇到各种坑。这里记录几个我亲身踩过或见同事踩过的典型问题。

6.1 异常与内存泄漏

这是最经典的问题。异常改变了控制流，如果资源不是由对象生命周期管理（即RAII），就极易泄漏。

void riskyFunction() {
    int* ptr = new int[100];
    someOperationThatMayThrow(); // 如果这里抛出异常...
    delete[] ptr; // 这行永远不会执行！
}

解决方案 ：无条件地使用智能指针（ std::unique_ptr , std::shared_ptr ）和RAII包装类（如 std::fstream , std::lock_guard ）。

void safeFunction() {
    auto ptr = std::make_unique<int[]>(100); // 使用智能指针
    someOperationThatMayThrow(); // 即使抛出异常，ptr的析构函数也会被调用，内存自动释放。
}

6.2 切片问题（Slicing）

在按值捕获异常时，如果捕获的是基类类型，而抛出的是派生类对象，会发生对象切片，丢失派生类的信息。

class BaseException : public std::exception { /* ... */ };
class NetworkException : public BaseException { /* 额外包含socket错误码 */ };

try {
    throw NetworkException(...);
} catch (const BaseException& e) { // 正确：按引用捕获
    // 可以访问派生类的虚函数
} catch (BaseException e) { // 错误：按值捕获，发生切片，NetworkException的额外信息丢失
}

黄金法则 ：总是按 const 引用捕获异常。

6.3 在构造函数初始化列表中抛出异常

这是一个棘手但重要的问题。如果在构造函数初始化列表中抛出异常，那么该对象被视为“从未完全构造”，其析构函数 不会 被调用。但是， 已经构造完毕的成员子对象和基类子对象的析构函数会被调用 。

class Member {
public:
    Member() { std::cout << "Member ctor\n"; }
    ~Member() { std::cout << "Member dtor\n"; }
};

class Base {
public:
    Base() { std::cout << "Base ctor\n"; }
    ~Base() { std::cout << "Base dtor\n"; }
};

class MyClass : public Base {
    Member m;
    std::unique_ptr<int> ptr;
public:
    MyClass(int val) : Base(), m(), ptr(std::make_unique<int>(val)) {
        // 构造函数体
        throw std::runtime_error("Oops in body");
    }
    ~MyClass() { std::cout << "MyClass dtor\n"; } // 不会被执行
};

// 调用时：try { MyClass obj(5); } catch(...) {}
// 输出：
// Base ctor
// Member ctor
// Member dtor <- Member已构造，所以会析构
// Base dtor   <- Base已构造，所以会析构
// MyClass dtor 不会输出，因为对象未完全构造。

关键点 ： ptr 的初始化（ std::make_unique ）如果失败抛出 std::bad_alloc ，那么 m 和 Base 的析构会被调用，但 MyClass 的析构不会。这要求成员对象和基类必须自己能处理构造失败的情况（通常通过RAII保证）。

6.4 排查“异常导致崩溃”的常用技巧

当程序因异常崩溃（如调用 std::terminate ）时，调试信息可能不完整。

1. 开启核心转储（Core Dump） ：在Linux下，使用 ulimit -c unlimited 并运行程序，崩溃后会生成core文件。用 gdb ./your_program core 加载，使用 bt （backtrace）命令查看崩溃时的完整堆栈。
2. 设置终止处理器 ：使用 std::set_terminate 安装一个自定义函数，在程序终止前打印一些信息或保存现场。

   void myTerminate() {
       std::cerr << "Uncaught exception! Stack trace:\n";
       // 这里可以尝试调用外部工具打印栈，如Linux的backtrace函数
       std::abort();
   }
   int main() {
       std::set_terminate(myTerminate);
       // ...
   }
   

3. 检查是否在析构函数中抛出了异常 ：这是导致 std::terminate 的常见原因。审查所有析构函数，确保它们都标记为 noexcept （C++11后默认）且内部不会抛出异常。
4. 使用编译器和链接器标志 ：GCC/Clang的 -fno-exceptions 会彻底改变行为。如果链接了启用异常的库和禁用异常的目标文件，可能会发生奇怪的链接错误或运行时崩溃。确保整个项目的异常设置一致。

7. 工具链与生态的影响

你的选择不仅影响代码，还影响整个开发工具链和生态系统。

7.1 编译器标志的连锁反应

如前所述， -fno-exceptions 是关键标志。但它意味着：

• 你不能使用 throw 、 try 、 catch 关键字。
• 许多标准库函数的行为会改变或不可用。例如， new 在失败时会返回 nullptr 而不是抛出 std::bad_alloc （但这需要配合 -fno-exceptions 和特定的 operator new 重载）。
• 你需要为你的项目及其所有依赖（如果可能）提供无异常的构建配置。

7.2 测试策略的调整

异常是错误路径的一部分，但错误码和 expected 同样需要测试。

• 对于异常 ：单元测试需要专门测试异常抛出是否合乎预期。Google Test 提供了 EXPECT_THROW 等断言。
• 对于错误码/expected ：测试需要覆盖所有可能的错误返回分支。这有时比测试异常更繁琐，因为你需要模拟各种失败条件（如磁盘满、网络断开）。
• 代码覆盖率 ：禁用异常后，那些原本由异常触发的错误处理代码（如清理资源的 catch 块）就不存在了，但这不代表错误处理代码变少，只是换成了 if (error) 分支。确保这些分支被测试覆盖同样重要。

7.3 静态分析工具

无论用哪种方式，静态分析工具都能帮助你发现潜在问题。

• Clang-Tidy ：有大量关于异常的检查，如 bugprone-exception-escape （检查析构函数是否可能抛出）、 hicpp-exception-baseclass （建议异常类继承自 std::exception ）。
• 对于禁用异常的项目 ：可以配置Clang-Tidy检查是否误用了可能抛出异常的标准库组件，或者检查错误码是否被忽略（结合 [[nodiscard]] ）。

说到底，关于C++异常的争论，本质上是C++语言“自由与责任”哲学的体现。它给了你强大的武器，但也要求你深刻理解其代价并承担正确使用的责任。大厂的“封杀”并非技术上的否定，而是在其特定规模、特定领域约束下的最优工程实践。作为开发者，最重要的不是站队，而是理解每种选择背后的“为什么”，然后根据你手头项目的具体需求——性能指标、团队习惯、代码库现状、依赖生态——做出最合适的技术决策。没有银弹，只有权衡。我的个人经验是，在新启动的、对性能不是极端敏感的应用层项目中，合理使用异常可以提升开发体验；而在底层基础设施、嵌入式或游戏引擎核心模块中，我会毫不犹豫地选择禁用异常，拥抱错误码或 expected ，换取那份确定性和可控性。