如何在C++中处理异常_C++异常处理机制详解

裘德小鎮的故事

发布时间：2025-09-19 09:16:02

874人浏览过

来源于php中文网

原创

C++异常机制通过try-catch结构分离错误检测与处理，结合RAII确保异常发生时资源能自动释放，适用于处理构造失败、资源获取失败等不可恢复错误，应避免用于常规控制流，且需注意性能开销主要在异常抛出时的栈展开，设计上需遵循异常安全级别与层次化异常类体系。

如何在c++中处理异常_c++异常处理机制详解

在C++中，处理程序运行时可能遇到的非预期情况，我们主要依赖异常机制。它提供了一种结构化的方式，将错误检测与错误处理分离开来，让代码在面对各种错误时能够更优雅、更健壮地响应，而不是简单地崩溃或返回难以追踪的错误码。这就像给你的程序安装了一个“安全气囊”，当发生碰撞（异常）时，它能迅速介入，避免更大的损害。

当程序执行过程中遇到无法按常规路径继续的情况，例如内存分配失败、文件打不开、无效的用户输入等，C++的异常处理机制就派上用场了。核心思路是，在可能出错的代码块周围放置一个

try

块，如果

try

块内的代码抛出了一个异常（使用

throw

关键字），那么程序的控制流就会立即跳转到最近的、匹配该异常类型的

catch

块。

例如，一个简单的场景是这样：

#include 
#include  // 包含标准异常类

double divide(double numerator, double denominator) {
    if (denominator == 0) {
        throw std::runtime_error("除数不能为零"); // 抛出一个运行时错误异常
    }
    return numerator / denominator;
}

int main() {
    try {
        double result = divide(10.0, 0.0);
        std::cout << "结果: " << result << std::endl;
    } catch (const std::runtime_error& e) { // 捕获std::runtime_error类型的异常
        std::cerr << "捕获到异常: " << e.what() << std::endl;
    } catch (const std::exception& e) { // 捕获所有标准异常的基类
        std::cerr << "捕获到其他标准异常: " << e.what() << std::endl;
    } catch (...) { // 捕获所有类型的异常 (通用捕获)
        std::cerr << "捕获到未知异常" << std::endl;
    }
    std::cout << "程序继续执行..." << std::endl;
    return 0;
}

这里，

divide

函数检查除数是否为零，如果是，就

throw

一个

std::runtime_error

异常。

main

函数中的

try

块尝试调用

divide

，一旦异常被抛出，

try

块中剩余的代码就会被跳过，程序会寻找匹配的

catch

块。在这个例子里，

catch (const std::runtime_error& e)

会捕获它，然后打印错误信息。

立即学习“C++免费学习笔记（深入）”；

C++异常处理与RAII（资源获取即初始化）是如何协同工作的？

在我看来，C++的异常处理机制如果离开了RAII（Resource Acquisition Is Initialization，资源获取即初始化），那它的威力至少要折损一半。RAII是C++中一个极其重要的编程范式，它利用对象生命周期来管理资源，确保资源在对象创建时被正确获取，在对象销毁时被正确释放。这在异常处理的上下文中显得尤为关键。

想象一下，如果你的函数在中间抛出了一个异常，那么函数执行路径就会突然中断，原本应该在函数末尾执行的资源清理代码（比如

delete

指针、关闭文件句柄、释放锁）就可能永远不会被执行到。这会导致内存泄漏、文件未关闭、死锁等严重问题。

而RAII的妙处就在于，它将资源封装在类的对象中。当一个对象被创建时（例如在栈上），它的构造函数负责获取资源。无论函数是正常返回还是因为抛出异常而退出，这个栈对象的析构函数都会被调用。析构函数就承担了释放资源的责任。这样一来，即使发生异常，资源也能得到妥善管理。

一个典型的例子就是智能指针，比如

std::unique_ptr

或

std::shared_ptr

。它们在构造时接管一个动态分配的内存，无论代码如何退出，只要智能指针对象超出作用域，其析构函数就会自动

delete

掉所管理的内存。

#include 
#include  // 包含智能指针
#include 

class MyResource {
public:
    MyResource(int id) : id_(id) {
        std::cout << "MyResource " << id_ << " acquired." << std::endl;
    }
    ~MyResource() {
        std::cout << "MyResource " << id_ << " released." << std::endl;
    }
    void do_something() {
        std::cout << "MyResource " << id_ << " doing something." << std::endl;
        // 假设这里可能抛出异常
        if (id_ == 2) {
            throw std::runtime_error("Resource 2 encountered an error!");
        }
    }
private:
    int id_;
};

void process_data() {
    std::unique_ptr res1 = std::make_unique(1);
    std::unique_ptr res2 = std::make_unique(2); // 这里的构造函数会执行

    res1->do_something();
    res2->do_something(); // 这里会抛出异常

    // 如果没有RAII，下面的资源清理代码可能不会执行
    // delete res1; // 假设是裸指针
    // delete res2;
}

int main() {
    try {
        process_data();
    } catch (const std::runtime_error& e) {
        std::cerr << "Caught exception in main: " << e.what() << std::endl;
    }
    std::cout << "Main function continues..." << std::endl;
    return 0;
}

在

process_data

函数中，即使

res2->do_something()

抛出了异常，

res1

和

res2

这两个

std::unique_ptr

对象也会在栈展开（stack unwinding）过程中被正确销毁，它们的析构函数会确保所管理的

MyResource

对象被释放。这正是RAII与异常处理的完美结合，它极大地简化了错误处理逻辑，减少了资源泄漏的风险。

Quinvio AI

AI辅助下快速创建视频，虚拟代言人

下载

何时应该使用C++异常，又该避免什么？

什么时候用异常，这是一个老生常谈的话题，也常常引发争论。我的观点是，异常处理机制最适合处理那些“真正异常”的、程序无法继续正常执行的错误情况。这些错误通常是无法预料的，或者说是程序逻辑设计上不希望发生的。

使用场景：
- 构造函数失败： 构造函数没有返回值，如果对象无法成功初始化，抛出异常是唯一的通知方式。
- 资源获取失败： 比如
```
new
```
  失败（虽然现在
```
new
```
  默认会抛
```
std::bad_alloc
```
  ），文件打开失败，网络连接失败等。
- 违反前置条件： 当一个函数被调用时，其输入参数不满足函数正常执行的最低要求，例如除数为零、数组索引越界（对于
```
std::vector::at()
```
  ）。
- 无法恢复的错误： 比如数据库连接中断，重要的配置项缺失，这些错误意味着程序无法继续提供预期服务。
避免什么：
- 不把异常当做常规控制流： 不要用异常来处理那些预期会频繁发生的、可以通过返回值或
```
bool
```
  标志轻松处理的“错误”。例如，遍历文件列表时，文件不存在不应该抛异常，而是返回一个表示“未找到”的状态。异常的开销相对较高，频繁使用会影响性能。
- 不要抛出宽泛的异常： 尽量使用特定类型的异常（继承自
```
std::exception
```
  的自定义异常或标准异常），这样
```
catch
```
  块可以更精确地处理。
```
throw "Error!"
```
  这种C风格字符串异常是非常不推荐的，因为它无法携带更多信息，且捕获困难。
- 不在析构函数中抛出异常： 析构函数抛出异常会导致严重的问题。如果析构函数在栈展开过程中（即另一个异常正在传播时）抛出异常，会导致程序终止（
```
std::terminate
```
  ）。析构函数应该只做清理工作，确保不抛出异常。
- 避免异常规范（
  throw()
  或
  noexcept
  ）的滥用：
```
noexcept
```
  是一个强有力的工具，但要谨慎使用。它表明函数不会抛出任何异常，如果真的抛出了，程序会直接终止。这对于优化器很有利，但如果误用，会掩盖真正的错误。对于那些确实不应该抛出异常的函数（比如移动构造函数、析构函数），使用
```
noexcept
```
  是很好的实践。

我的经验是，异常处理机制应该像消防栓一样，在真正需要的时候能派上用场，而不是像日常用水龙头那样频繁使用。过度依赖异常会使代码的控制流变得难以预测和调试。

理解C++异常的性能开销与设计考量

关于C++异常的性能开销，这确实是一个值得深入探讨的话题。很多人对异常的使用持谨慎态度，部分原因就是担心其性能影响。

性能开销：
- 栈展开（Stack Unwinding）： 当异常被抛出时，程序会沿着函数调用栈向后回溯，依次调用局部对象的析构函数，直到找到一个匹配的
```
catch
```
  块。这个过程称为栈展开。栈展开本身是有开销的，因为它需要遍历栈帧，执行清理工作。
- 异常对象构造与复制： 抛出异常时，异常对象会被构造，并可能在内部进行复制。这涉及到内存分配和对象拷贝，都会带来性能损耗。
- 二进制大小： 编译器为了支持异常处理，会在生成代码时加入额外的元数据和指令，这可能会增加最终可执行文件的大小。
- try
  块的开销：现代C++编译器对
```
try
```
  块的优化已经相当好，在没有异常抛出的“正常”路径下，
```
try
```
  块本身的开销通常很小，甚至可以忽略不计。主要的开销发生在异常真正被抛出并捕获时。

所以，一个关键点是，如果异常很少发生，那么异常处理的总体性能影响可能远低于其带来的代码清晰度和健壮性收益。如果异常频繁发生，那么确实需要重新审视设计，可能它并不是一个“异常”情况，而应该用其他方式处理。

设计考量：
- 异常安全（Exception Safety）： 这是使用异常时最重要的设计原则之一。它要求即使在异常发生时，程序也能保持有效状态，不泄漏资源，不破坏数据完整性。通常分为三个级别：
  - 基本保证： 如果操作失败，程序状态保持有效，但不保证数据值不变。资源不泄漏。
  - 强保证： 如果操作失败，程序状态回滚到操作开始前的状态。就像操作从未发生过一样。
  - 不抛出保证（No-throw Guarantee）： 操作永远不会抛出异常。这通常通过
```
noexcept
```
    关键字来强制。
- 异常层次结构： 设计良好的异常类应该形成一个层次结构，继承自
```
std::exception
```
  ，并提供有意义的
```
what()
```
  方法。这样，
```
catch
```
  块可以捕获更具体的异常，也可以捕获基类来处理一类异常。
- 异常边界： 应该明确在哪里捕获异常。通常，在库函数或底层模块中抛出异常，而在应用程序的更高层级（例如用户界面层、主循环）捕获并处理它们。过早捕获可能导致错误信息丢失，过晚捕获可能导致程序崩溃。
- 避免“裸”指针和手动资源管理： 再次强调RAII的重要性。在C++中，几乎所有资源都应该通过RAII对象来管理，这是实现异常安全的关键基石。

总而言之，异常处理是C++中一个强大而复杂的特性。它不是银弹，也不是用来替代所有错误码的工具。理解其工作原理、性能特点以及与RAII等机制的协同作用，才能在实际项目中更好地驾驭它，写出既健壮又高效的代码。我的建议是，在设计系统时，先思考哪些情况是“正常”的错误，可以通过返回值处理；哪些是“异常”情况，程序无法继续，需要通过异常来中断并清理。这样，才能真正发挥异常处理的价值。

c++中如何使用std::prev和std::next操作迭代器_c++迭代器偏移【汇总】

c++中的std::back_inserter是如何工作的？ (输出迭代器)

C++中的noexcept关键字有什么用？(向编译器保证函数不抛出异常)

c++中如何使用std::exchange_c++替换值并返回旧值的方法【实例】

C++项目架构设计：基于Core Guidelines的模块划分策略【大型工程实践】