从错误码到栈展开: 我如何理解 C++ 异常

异常最基本的语法#

抛出异常使用 throw：

1
double divide(double a, double b) {
2
  if (b == 0.0) {
3
    throw std::invalid_argument("division by zero");
4
  }
5

6
  return a / b;
7
}

调用者使用 try 和 catch：

1
try {
2
  double result = divide(10.0, 0.0);
3
  std::cout << result << '\n';
4
} catch (const std::invalid_argument& error) {
5
  std::cerr << "参数错误: " << error.what() << '\n';
6
}

几个基本规则：

1
try {
2
  // 可能抛出异常的代码
3
} catch (const SpecificException& error) {
4
  // 处理特定异常
5
} catch (const std::exception& error) {
6
  // 处理其他标准异常
7
} catch (...) {
8
  // 处理所有其他异常
9
}

异常一般按值抛出、按 const 引用捕获：

1
throw MyException{"motor stalled"};
2

3
catch (const MyException& error) {
4
  // ...
5
}

不要按值捕获：

1
catch (std::exception error) {  // 不推荐
2
}

这可能发生对象切片，丢失派生异常中的信息。

抛出以后发生了什么？#

假设调用链是：

如果 read_file() 抛出异常，它不会像错误码那样正常返回。C++ 会沿调用栈向上寻找匹配的 catch：

这个过程叫做栈展开，stack unwinding。

在展开过程中，已经构造完成的局部对象会被自动销毁：

1
void process() {
2
  std::vector<int> data(1000);
3
  std::lock_guard<std::mutex> lock(mutex);
4

5
  perform_operation();  // 抛出异常
6
}

即使 perform_operation() 抛出异常：

• lock 的析构函数仍然执行，互斥锁被释放；
• data 的析构函数仍然执行，内存被释放。

1
#include <iostream>
2
#include <stdexcept>
3
#include <string_view>
4

5
class Trace {
6
 public:
7
  explicit Trace(std::string_view name) : name_(name) {
8
    std::cout << "construct " << name_ << '\n';
9
  }
10

11
  ~Trace() { std::cout << "destroy " << name_ << '\n'; }
12

13
 private:
14
  std::string_view name_;
15
};
16

17
void read_file() {
18
  Trace trace{"read_file"};
19
  throw std::runtime_error{"disk error"};
20
}
21

22
void load_configuration() {
23
  Trace trace{"load_configuration"};
24
  read_file();
25
}
26

27
int main() {
28
  try {
29
    Trace trace{"main"};
30
    load_configuration();
31
  } catch (const std::runtime_error& error) {
32
    std::cout << "catch runtime_error: " << error.what() << '\n';
33
  }
34
}

1
construct main
2
construct load_configuration
3
construct read_file
4
destroy read_file
5
destroy load_configuration
6
destroy main
7
catch runtime_error: disk error

1
Resource* resource = acquire();
2

3
try {
4
  use(resource);
5
} catch (...) {
6
  release(resource);
7
  throw;
8
}
9

10
release(resource);

1
auto resource = make_resource();
2
use(resource);

throw; 和 throw e; 不一样#

捕获后重新抛出当前异常：

1
catch (const std::exception& error) {
2
  log_error(error.what());
3
  throw;
4
}

这里应当使用没有参数的 throw;。它重新抛出当前正在处理的异常，保留原始异常对象及其动态类型。

不要写：

1
catch (const std::exception& error) {
2
  throw error;
3
}

这会用表达式 e 的静态类型 std::exception 初始化一个新的异常对象，因此派生部分会被切掉。

自定义异常#

自定义异常通常继承 std::runtime_error：

1
class ConfigurationError : public std::runtime_error {
2
 public:
3
  using std::runtime_error::runtime_error;
4
};

使用：

1
void load_configuration() {
2
  if (!configuration_exists()) {
3
    throw ConfigurationError{"configuration file is missing"};
4
  }
5
}

捕获：

1
catch (const ConfigurationError& error) {
2
  std::cerr << "配置错误: " << error.what() << '\n';
3
}

不要为每一种小错误都创建一个异常类。异常类型的价值在于让调用者能够采取不同措施，而不仅仅是让类名看起来很完整。

如果两个错误的处理策略完全一样，它们很可能不需要两个异常类型。

到底什么时候应该抛异常？#

我认为最有用的判断标准是：

例如：

1
Configuration load_configuration(const std::filesystem::path& path);

这个函数承诺返回一个有效配置。如果文件损坏，函数无法兑现承诺。此时抛异常很自然：

1
Configuration load_configuration(const std::filesystem::path& path) {
2
  std::ifstream input(path);
3

4
  if (!input) {
5
    throw ConfigurationError{
6
      "cannot open configuration: " + path.string()};
7
  }
8

9
  return parse_configuration(input);
10
}

特别适合异常的情况包括：

• 构造函数无法建立对象不变量；
• 初始化过程失败，程序无法继续；
• 文件、数据库或系统资源出现罕见故障；
• 某个深层函数无法处理错误，需要跨越多层调用栈；
• 函数通常成功，而失败属于异常路径。

构造函数尤其适合异常，因为构造函数没有返回值可以装错误码：

1
class SerialPort {
2
 public:
3
  explicit SerialPort(const std::string& device) {
4
    // 约定 open_device 成功时返回空 error_code。
5
    if (const std::error_code error = open_device(device)) {
6
      throw std::system_error{error,
7
                              "cannot open serial port " + device};
8
    }
9
  }
10
};

要么构造出一个有效的 SerialPort，要么构造失败并抛出。不会产生一个”半死不活、需要调用 is_valid() 才敢使用”的对象。

什么情况不应该抛异常？#

异常不适合表达正常、频繁、可预期的业务分支。

例如查找元素：

1
const User* find_user(UserId id);

“没有找到用户”可能完全正常，因此返回空指针或 std::optional 更合适：

1
std::optional<User> find_user(UserId id);

类似情况还有：

• 队列当前为空；
• 非阻塞读取暂时没有数据；
• 用户输入不符合格式；
• 网络操作需要重试；
• 传感器偶尔超时，而超时是协议的一部分；
• 解析器试探某种语法但没有匹配；
• 高频控制循环中的状态变化。

在 C++23 中，还可以使用 std::expected<T, E>：

1
enum class SensorError {
2
  kTimeout,
3
  kDisconnected,
4
  kChecksumError,
5
};
6

7
std::expected<Reading, SensorError> read_sensor();

调用者显式处理：

1
auto result = read_sensor();
2

3
if (!result) {
4
  if (result.error() == SensorError::kTimeout) {
5
    retry();
6
  }
7
  return;
8
}
9

10
process(*result);

我通常这样区分：

异常不是”更高级的错误码”。它们适合不同形状的控制流。

应该在哪里捕获？#

这是异常设计中最重要的问题。答案不是”尽量靠近抛出点”，而是：

在能够采取有意义行动的层级捕获。

所谓有意义行动，大致只有几种：

• 重试操作；
• 使用备用方案；
• 请求用户提供新的输入；
• 把底层错误翻译成当前层的领域错误；
• 回滚当前事务；
• 结束当前请求，但保持整个服务继续运行；
• 在程序最外层记录错误并安全退出。

如果某一层什么都做不了，就不应该为了”看起来处理了错误”而捕获。

这种代码几乎没有价值：

1
try {
2
  load_configuration();
3
} catch (const std::exception& error) {
4
  throw;
5
}

它只是把异常接住，然后原样扔回去。除非这里需要补充上下文，否则让异常自然传播即可。

1
std::string read_file(const std::filesystem::path& path);
2
Configuration load_configuration(const std::filesystem::path& path);
3
void initialize_application();
4
int main();

1
std::string read_file(const std::filesystem::path& path) {
2
  std::ifstream input(path);
3

4
  if (!input) {
5
    // 不从 errno 猜测 iostream 失败的原因。
6
    throw std::ios_base::failure{"cannot open " + path.string()};
7
  }
8

9
  return {std::istreambuf_iterator<char>{input},
10
          std::istreambuf_iterator<char>{}};
11
}

1
Configuration load_configuration(const std::filesystem::path& path) {
2
  try {
3
    return parse_configuration(read_file(path));
4
  } catch (const std::system_error& error) {
5
    std::throw_with_nested(ConfigurationError{
6
      "failed to load application configuration"});
7
  }
8
}

1
int main() {
2
  try {
3
    auto config = load_configuration("app.conf");
4
    run_application(config);
5
    return EXIT_SUCCESS;
6
  } catch (const ConfigurationError& error) {
7
    std::cerr << "程序无法启动: " << error.what() << '\n';
8
    return EXIT_FAILURE;
9
  } catch (const std::exception& error) {
10
    std::cerr << "未处理的错误: " << error.what() << '\n';
11
    return EXIT_FAILURE;
12
  }
13
}

捕获异常不等于”解决异常”#

这是一个非常常见的困惑。

假设串口打开失败：

1
throw SerialPortError{"COM3 is unavailable"};

捕获以后，你不一定能”修好 COM3”。处理异常可能只是：

• 尝试另一个串口；
• 等待一秒后重试；
• 提示用户检查连接；
• 禁用相关功能；
• 记录错误并结束程序。

“处理”指的是把系统带到一个定义良好的状态，而不是必须让原操作成功。

如果当前层做不到这一点，就继续传播。

try 块中的代码是不是应该尽量少？#

不是因为 try 天生按行收费，而是因为语义。

在 GCC、Clang 和 MSVC 常见的表驱动异常实现中，未抛出异常的正常路径通常不需要像错误码那样在每一层增加显式分支。代价主要转移到了异常处理元数据、二进制体积和真正抛出时的工作；这是一种常见实现策略，不是 C++ 标准给出的性能保证。

try 里面有十行还是一百行，并不是主要性能因素。

不过，过大的 try 块会造成另一个问题：

1
try {
2
  load_config();
3
  connect_database();
4
  start_network();
5
  initialize_ui();
6
} catch (const std::exception& error) {
7
  // 到底哪一步失败了？
8
}

这里捕获得太宽，错误上下文容易变模糊。可以让各层的异常信息足够明确，或者按恢复策略划分边界。

所以更准确的原则是：

嵌入式项目为什么经常禁用异常？#

在嵌入式和硬实时系统里，避免异常往往是合理的。原因可能包括：

• 栈展开延迟难以严格界定；
• 异常处理会增加代码体积和展开表；
• 工具链或运行库支持不完整；
• 项目禁止动态内存分配；
• 中断服务函数不能允许非局部控制流；
• 安全规范要求所有控制路径显式可分析；
• 项目直接使用了 -fno-exceptions。

因此我不会提出”现代 C++ 就应该全面使用异常”这种宗教口号。对于嵌入式代码，下面这种组合通常很实际：

• 中断、驱动、实时循环：错误码或 expected；
• 上层非实时业务逻辑：根据项目约束决定是否允许异常；
• 初始化阶段：如果允许异常，异常往往很好用；
• 跨 C ABI 边界：绝不让异常逃出；
• 析构函数：通常不得抛出异常。

1
extern "C" int initialize_device() {
2
  try {
3
    initialize_cpp_subsystem();
4
    return 0;
5
  } catch (const std::exception& error) {
6
    log_error(error.what());
7
    return -1;
8
  }
9
}

异常在 C++ 边界内结束，转换为 C 能理解的错误码。

noexcept 是一份承诺#

可以声明某个函数不允许异常逃出：

1
void stop_motor() noexcept;

析构函数通常隐式为 noexcept；但如果它的基类或成员析构函数可能抛出，这个结论也会跟着改变。如果异常从非抛出的析构函数逃出，程序会调用 std::terminate()；若此时本来就在栈展开，结果同样是直接终止。

所以析构函数负责释放资源，但不应该通过异常报告清理失败：

1
Connection::~Connection() noexcept {
2
  close_without_throwing();
3
}

异常安全比”有没有 catch”更重要#

一个函数抛出异常后，对象和程序应该处于什么状态？

C++ 通常讨论三种保证：

1. 基本保证：没有资源泄漏，对象仍然有效，但状态可能改变。
2. 强保证：操作失败后，状态和调用前完全一致，类似事务回滚。
3. 不抛保证：函数保证不抛异常。

例如，先构造新状态，成功后再替换旧状态：

1
void Document::set_content(std::string new_content) {
2
  validate(new_content);       // 可能抛出，尚未修改原对象
3
  content_.swap(new_content);  // C++17 起 std::string::swap 为 noexcept
4
}

验证失败时，原内容没有被修改；交换成功后，旧内容由参数 new_content 在离开函数时销毁。这里给出强异常保证，而不是仅仅”接近”它。

相比之下：

1
void update() {
2
  state_.clear();
3
  state_.load();  // 如果这里抛出，旧状态已经丢失
4
}

这里即使外层正确捕获异常，对象也可能已经处于不理想的状态。

所以异常设计的真正难点不是 try/catch 语法，而是：

我最终会采用的规则#

如果我要从嵌入式 C 迁移到现代 C++，我会先使用下面这套相对保守的规则：

• 预期内、频繁发生、调用者立即处理的失败，使用 std::expected、std::optional 或错误码。
• 罕见且无法在本地处理、需要跨越多层调用的失败，可以抛异常。
• 构造函数无法建立有效对象时，抛异常。
• 只在能够重试、降级、翻译、回滚或终止当前任务的边界捕获。
• 不要每层都捕获并重新抛出。
• 异常按值抛出，按 const 引用捕获。
• 重新抛出使用 throw;。
• 用 RAII 管理资源，不要依赖 catch 手动释放。
• 析构函数、C 接口和实时路径不允许异常逃出。
• 不用异常表示普通分支，也不用错误码掩盖真正无法继续的故障。
• 不担心 try 块里有几行代码；担心的是异常是否频繁发生，以及恢复边界是否清晰。

最简洁的判断方式可能是：

异常最适合的角色不是代替所有错误码，而是处理那些”这里已经无法继续，但更高层仍然知道该怎么办”的失败。

底层负责准确报告，中层负责维持不变量，边界层负责恢复或终止。至于每个函数都写一个 try/catch - 大可不必，那只是把错误码时代的 if (error) 换了一件稍微昂贵一点的外套。