怎样在C++中重新抛出异常并保留原始异常信息？

在C++异常处理过程中，一个常见需求是：捕获异常后先执行一些清理或记录操作，再将同一个异常继续向上层传递。如果只是简单地创建一个新异常并抛出，很可能会破坏原始异常的类型信息和诊断上下文。直接使用throw new_exception;会让调用方只能捕获到新异常，而无法得知最初是哪个底层错误触发了异常链。这篇文章将围绕throw;、std::exception_ptr和嵌套异常三种机制，详细说明如何在C++中安全地重新抛出异常并保留原始异常信息。

一、使用无操作数throw;重新抛出当前活动异常

在catch块内部，C++提供了一种特殊的throw;语法，它不带任何操作数，作用是重新抛出当前正在处理的异常。这个语法与throw e;有本质区别：throw;不会复制异常对象，而是将当前活动异常重新激活并向外层传播，因此原始异常对象的动态类型、what()返回的信息以及可能包含的自定义成员都完整保留。

与之相对，throw e;会以静态类型复制异常对象。如果e的静态类型是基类引用，而实际异常对象是派生类，就会发生对象切片，派生类特有的信息被截断，上层调用者无法通过catch匹配到原始派生类类型。下面这个例子展示了切片问题：

#include <iostream>
#include <exception>

class BaseError : public std::exception {
public:
    const char* what() const noexcept override { return "BaseError"; }
};

class DerivedError : public BaseError {
public:
    const char* what() const noexcept override { return "DerivedError"; }
};

void inner() {
    throw DerivedError();
}

void middle() {
    try {
        inner();
    } catch (const BaseError& e) {
        // 错误示范：throw e 会复制为BaseError，丢失DerivedError信息
        throw e;
    }
}

int main() {
    try {
        middle();
    } catch (const DerivedError& e) {
        std::cout << "Caught DerivedError: " << e.what() << std::endl;
    } catch (const BaseError& e) {
        std::cout << "Caught BaseError: " << e.what() << std::endl;
    }
}

运行上述代码会发现，即使inner()抛出的是DerivedError，由于middle()中使用了throw e;，异常被复制成BaseError类型，外层捕获到的是BaseError。throw;的正确写法如下：

void middle() {
    try {
        inner();
    } catch (...) {
        // 执行清理或日志操作
        throw; // 重新抛出当前活动异常，保留完整类型
    }
}

这里需要注意，throw;只能出现在catch块内部，或者由catch块直接或间接调用的函数中，并且当前必须存在一个正在处理的异常。如果在没有活动异常的情况下执行throw;，程序会调用std::terminate终止。因此，在catch块外使用throw;是危险的。

此外，catch(...)中使用throw;也是合法的，它会重新抛出未知类型的原始异常，而不需要显式写出异常类型。这很适合那些只做资源清理、不关心异常具体类型的场景。

二、用std::exception_ptr保存异常并延迟重新抛出

std::exception_ptr是C++11引入的一种特殊指针类型，它可以持有任意异常对象的副本。在catch块中调用std::current_exception()可以获取当前活动异常并返回一个std::exception_ptr，之后在任意时间点调用std::rethrow_exception(ptr)即可重新抛出该异常。这种方式最大的好处是支持异常的暂存和跨线程传递。

典型场景是：一个工作线程在运行过程中抛出了异常，主线程希望在工作线程结束后重新获取这个异常并处理。若没有exception_ptr，异常只能在工作线程内部被处理，无法跨线程传播。下面是一个将工作线程异常保存到全局变量，并在主线程重新抛出的示例：

#include <iostream>
#include <exception>
#include <thread>
#include <mutex>

std::exception_ptr g_exception;
std::mutex g_mutex;

void worker() {
    try {
        throw std::runtime_error("worker failed");
    } catch (...) {
        std::lock_guard<std::mutex> lock(g_mutex);
        g_exception = std::current_exception();
    }
}

int main() {
    std::thread t(worker);
    t.join();
    if (g_exception) {
        try {
            std::rethrow_exception(g_exception);
        } catch (const std::exception& e) {
            std::cout << "Caught from worker: " << e.what() << std::endl;
        }
    }
    return 0;
}

这段代码中，worker()捕获异常后通过current_exception()生成exception_ptr并存放到全局变量。主线程在join后检查该指针是否有效，有效则调用std::rethrow_exception重新抛出，然后在try块中捕获并处理。由于exception_ptr保存的是原始异常对象的副本，因此即使异常类型是派生类，重新抛出后仍然能按原始类型捕获，不会发生切片。

需要注意，std::exception_ptr内部使用引用计数机制管理异常对象，多个exception_ptr副本会共享同一个异常对象，因此可以安全地复制。但std::current_exception()只能在catch块中调用，否则返回一个空的exception_ptr。另外，每次调用std::rethrow_exception(ptr)都会重新抛出异常，如果调用方不再需要该异常，可以清空exception_ptr以避免重复抛出造成逻辑混乱。

在多线程环境中，对exception_ptr的读写需要同步保护，示例中使用了std::mutex和std::lock_guard来保证安全。

三、利用嵌套异常保留异常链信息

当程序需要在一个异常处理过程中抛出另一个异常，但又不想丢失原始异常时，可以使用C++11提供的嵌套异常机制。核心函数是std::throw_with_nested(new_exception)和std::rethrow_if_nested(e)。前者在抛出new_exception的同时，将当前活动异常嵌套进去；后者在捕获到外层异常后，如果其中包含嵌套的原始异常，则重新抛出该嵌套异常，否则不做任何操作。

这种机制特别适合分层架构。例如数据库访问层捕获了底层网络异常，需要向上层抛出一个数据库相关异常，但底层网络异常的具体信息对调试和定位问题非常重要。直接抛出新异常会掩盖根因，而嵌套异常可以保留完整的异常链。

#include <iostream>
#include <exception>
#include <stdexcept>

void network_call() {
    throw std::runtime_error("connection reset");
}

void db_query() {
    try {
        network_call();
    } catch (...) {
        std::throw_with_nested(std::runtime_error("database query failed"));
    }
}

int main() {
    try {
        db_query();
    } catch (const std::exception& e) {
        std::cout << e.what() << std::endl;
        try {
            std::rethrow_if_nested(e);
        } catch (const std::exception& nested) {
            std::cout << "Caused by: " << nested.what() << std::endl;
        }
    }
    return 0;
}

在这个例子中，network_call()抛出std::runtime_error，db_query()捕获到该异常后调用std::throw_with_nested抛出一个新的std::runtime_error。新异常内部自动保存了原始异常对象。上层main()捕获到外层异常后，调用std::rethrow_if_nested(e)，这会重新抛出原始的connection reset异常，从而打印出完整的异常链。

实现上，std::throw_with_nested会抛出一个特殊类型std::nested_exception的派生对象，该类继承自std::exception并持有一个std::exception_ptr。外层异常对象实际是std::nested_exception的子类与用户异常类型组合后的对象。当调用std::rethrow_if_nested(e)时，函数会检查e是否继承自std::nested_exception，如果是则取出内部exception_ptr并重新抛出。这一机制保证了异常类型信息不被破坏。

需要注意，std::throw_with_nested必须在catch块中调用，否则没有活动异常可以嵌套，它就会直接抛出参数指定的异常，相当于普通throw。此外，嵌套异常可以形成多级链，例如在捕获嵌套异常后再次调用throw_with_nested，上层可以递归使用rethrow_if_nested来遍历每一层。

四、通过自定义异常类手动保存原始异常

标准库提供的机制已经覆盖了大多数场景，但在一些业务需求中，异常对象还需要携带额外的上下文信息，例如错误码、请求ID、用户标识等。此时可以自定义异常类，在构造函数中接收std::exception_ptr以及必要的上下文数据，并在需要时提供方法重新抛出原始异常。

下面是一个自定义包装异常类的示例：

#include <exception>
#include <string>
#include <memory>

class WrappedError : public std::exception {
    std::exception_ptr original_;
    std::string message_;
    int error_code_;
public:
    WrappedError(const std::string& msg, int code, std::exception_ptr original)
        : original_(original), message_(msg), error_code_(code) {}

    const char* what() const noexcept override {
        return message_.c_str();
    }

    int error_code() const noexcept {
        return error_code_;
    }

    void rethrow_original() const {
        if (original_) {
            std::rethrow_exception(original_);
        }
    }
};

void do_work() {
    try {
        // 模拟底层操作
        throw std::runtime_error("low-level failure");
    } catch (...) {
        throw WrappedError("high-level operation failed", 1001, std::current_exception());
    }
}

在这个类中，original_保存了原始异常，error_code_保存业务错误码。上层捕获WrappedError后，可以通过rethrow_original()重新抛出底层异常，也可以直接读取error_code()获取上下文。这种方式给予了开发者最大的控制权。

不过，使用自定义异常类时也要注意异常对象复制可能导致切片的问题。如果异常类被按值捕获或复制，派生类成员可能会丢失。因此建议在catch子句中始终按引用捕获异常，如catch (const WrappedError& e)。此外，std::exception_ptr的引入使得保存异常对象变得轻量且安全，比手动保存std::exception的副本更可靠。

综合来看，如果只是简单地转发当前异常，throw;最为简洁高效；如果需要在不同线程或异步任务中传递异常，std::exception_ptr是首选；如果希望在异常传播过程中添加上下文并保持异常链，嵌套异常机制最合适；而当业务需要携带结构化上下文时，自定义异常类结合exception_ptr是灵活且可扩展的方案。理解这些工具的区别并合理选用，能够显著提升C++异常处理代码的健壮性和可维护性。

C++异常处理重新抛出异常std::exception_ptr修改时间：2026-09-30 04:23:07