49. 移动语义与异常处理：在构造函数中抛出异常时，如何保证资源安全？

这个问题，说实话，是C++异常安全编程里最让人头疼的角落之一。你想想看，构造函数里抛异常，对象还没构造完呢，析构函数根本不会调用。那已经分配的资源怎么办？

我早年接手过一个遗留系统，里面有个大对象，构造函数里要开文件、要申请网络连接、还要分配一大块共享内存。结果有一次线上环境磁盘满了，文件打开失败，构造函数直接抛了个异常出去。好家伙，共享内存已经分配了，没人去释放，系统内存泄漏了整整一个周末才被发现。

从那以后，我对构造函数里的异常处理就格外敏感。今天咱们就好好聊聊，在移动语义的背景下，怎么把这块烫手山芋接住。

核心问题：半构造对象

先理清一个基本事实：C++规定，如果构造函数抛出异常，该对象的析构函数不会被调用。为什么？因为对象压根没构造完，C++运行时认为它不存在。但问题是，构造函数里可能已经分配了部分资源——比如已经new了一块内存，或者已经打开了一个文件句柄。

这就造成了所谓的「半构造对象」困境。资源已经出去了，但没人负责回收。

移动语义带来的新挑战

移动语义引入后，情况变得更微妙了。因为移动操作通常被设计成「不抛异常」的（用 noexcept 标记），但构造函数本身可能因为其他原因抛异常。比如：

class BigBuffer {
    char* data_;
    size_t size_;
public:
    BigBuffer(size_t n) 
        : data_(new char[n]), size_(n) 
    {
        // 假设这里做一些初始化操作，可能抛异常
        if (some_condition()) {
            throw std::runtime_error("初始化失败");
        }
    }
    
    ~BigBuffer() { delete[] data_; }
    
    // 移动构造函数
    BigBuffer(BigBuffer&& other) noexcept
        : data_(other.data_), size_(other.size_)
    {
        other.data_ = nullptr;
        other.size_ = 0;
    }
};

你看，移动构造函数是 noexcept 的，这没问题。但普通构造函数里如果抛异常，data_ 已经 new 出来了，谁来释放？答案是：没人。因为析构函数不会执行。

解决方案一：RAII 包装器（我最推荐的方式）

说白了，就是别让裸资源直接出现在类里。用智能指针、unique_ptr、shared_ptr 或者自定义的 RAII 包装类来管理每个资源。这样即使构造函数中途抛异常，已经构造好的成员变量会自动析构。

class SafeBigBuffer {
    std::unique_ptr<char[]> data_;
    size_t size_;
public:
    SafeBigBuffer(size_t n) 
        : data_(std::make_unique<char[]>(n)), size_(n)
    {
        // 这里抛异常也没关系
        // data_ 是 unique_ptr，会自动释放
        if (some_condition()) {
            throw std::runtime_error("初始化失败");
        }
    }
    
    // 移动构造函数自动生成，且是 noexcept 的
    SafeBigBuffer(SafeBigBuffer&&) = default;
};

解决方案二：函数 try 块（Function Try Block）

这个语法比较冷门，但确实有用。它允许你在构造函数体外面捕获异常，并在捕获后做一些清理工作。

class FileAndMemory {
    FILE* file_;
    char* buffer_;
public:
    FileAndMemory(const char* filename, size_t buf_size)
        try 
            : file_(fopen(filename, "r")), 
              buffer_(new char[buf_size])
        {
            // 构造函数体
            if (!file_) {
                throw std::runtime_error("文件打开失败");
            }
        }
        catch (...) {
            // 注意：这里可以访问成员变量
            delete[] buffer_;
            if (file_) fclose(file_);
            throw; // 必须重新抛出
        }
};

嗯，这里有个坑要注意：函数 try 块里捕获异常后，必须重新抛出。如果你不重新抛，C++ 运行时会在 catch 块末尾自动帮你重新抛。而且，在 catch 块里你只能做清理工作，不能「吞掉」异常假装什么都没发生。

解决方案三：两阶段构造（不推荐，但了解一下）

有些老代码会采用「两阶段构造」：构造函数只做简单的成员初始化，真正的资源分配放在一个单独的 init() 函数里。这样 init() 抛异常时，对象已经构造完成了，析构函数可以正常调用。

class TwoPhase {
    char* data_;
    bool initialized_;
public:
    TwoPhase() : data_(nullptr), initialized_(false) {}
    
    void init(size_t n) {
        data_ = new char[n];
        initialized_ = true;
        // 这里抛异常的话，data_ 会泄漏
        // 所以 init 内部也要用 RAII
    }
    
    ~TwoPhase() {
        if (initialized_) delete[] data_;
    }
};

说实话，我不推荐这种方式。它破坏了 RAII 的原则，让对象处于「有效但未初始化」的状态，调用者很容易忘记调用 init()。我在项目里见过因此导致的崩溃，排查起来特别痛苦。

移动语义与异常安全的结合

现在我们把移动语义和异常安全放在一起看。一个常见的模式是：用移动操作来「转移」资源所有权，从而避免构造函数里的复杂资源管理。

class ResourceHolder {
    std::vector<char> data_;
    std::unique_ptr<SomeDevice> device_;
public:
    // 构造函数只做简单的移动操作
    ResourceHolder(std::vector<char> data, std::unique_ptr<SomeDevice> dev)
        : data_(std::move(data)), device_(std::move(dev))
    {
        // 这里如果抛异常，data_ 和 device_ 已经构造好了
        // 它们的析构函数会自动处理
        if (!device_->is_ready()) {
            throw std::runtime_error("设备未就绪");
        }
    }
};

你看，关键思路是：把资源管理的复杂性推到各个成员变量的构造函数里。每个成员变量自己负责自己的资源安全。这样外层构造函数即使抛异常，成员变量们也能各自安好。

避坑指南：移动操作必须是 noexcept

我曾经踩过一个坑：标准库容器（比如 std::vector）在重新分配内存时，如果元素的移动构造函数不是 noexcept 的，它会退而使用拷贝构造函数。这会导致性能骤降。

所以，如果你自定义了移动构造函数，一定要记得加上 noexcept：

class MyType {
public:
    MyType(MyType&& other) noexcept 
        : /* 成员移动 */ 
    {}
};

为什么？因为 std::vector 在扩容时，如果移动构造函数可能抛异常，它不敢用移动，只能用拷贝——拷贝至少能保证原对象不变。这其实是一种异常安全策略，但代价是性能。

流程图：构造函数异常时的资源安全策略

最后说两句

异常安全这个话题，说深了可以写一本书。但核心原则其实很简单：让每个资源都有自己的「管家」。这个管家（RAII 包装器）负责资源的生命周期，不管构造函数在哪一步抛异常，管家们都会尽职尽责地完成清理工作。

我在代码审查时，看到裸 new 和裸 delete 出现在构造函数里，基本都会打回去让改。不是教条，是真的被坑怕了。你想想看，一个线上服务跑得好好的，突然因为某个构造函数抛异常导致内存泄漏，然后慢慢把系统拖死——这种问题排查起来，比写代码时多花几秒钟用 unique_ptr 要痛苦得多。

记住：移动语义和异常安全不是对立的，它们可以很好地协作。关键是让移动操作保持 noexcept，让资源管理保持 RAII。这样你的代码既高效，又安全。

---

公众号:蓝海资料掘金营，微信deep3321