第22章移动语义与异常

课程目录第22章移动语义与异常

22. 移动语义与异常：移动操作抛出异常时的回退机制

异常和移动语义，这两个东西单独拎出来都不算简单。把它们放在一起，嗯，确实容易让人头疼。

我记得几年前在一个高并发服务里，我写了一个自定义容器。当时为了追求极致性能，移动构造函数里用了不少底层资源转移。结果上线第一天，某个极端情况下移动操作抛异常了——整个数据结构的内部状态变得一团糟。从那以后，我对「移动操作到底该不该抛异常」这个问题，有了切肤之痛的理解。

这一章，我们就来聊聊这个容易被忽视、但一旦踩坑就很要命的话题。

22.1 移动操作的基本原则：不抛异常

先说结论：移动构造函数和移动赋值运算符，应该被设计为不抛出异常。这不是C++标准强制要求的，但几乎所有现代C++代码库都遵循这个潜规则。

为什么？因为标准库容器（比如 std::vector）在做内存重分配时，会优先选择移动操作。但如果移动操作可能抛异常，容器就不得不退回到拷贝操作——这会导致性能大幅下降。

核心原则：如果移动操作可能抛异常，请用 noexcept 明确声明。否则，标准库会认为它不安全，从而选择拷贝。

说白了，你写 noexcept 不只是告诉编译器「我不抛异常」，更是在告诉标准库：「放心用我的移动操作，不会出事」。

22.2 为什么移动操作会抛异常？

理论上，移动操作只是「偷」资源——把指针、句柄、文件描述符这些从源对象转移到目标对象。这个过程不应该涉及内存分配、文件读写等可能失败的操作。

但现实往往没那么理想。我在项目中遇到过几种常见情况：

移动构造函数中调用了可能抛异常的函数，比如 std::vector 的拷贝构造（虽然移动不应该拷贝）
自定义资源管理类，移动时需要申请新的系统资源（比如打开一个新文件句柄）
第三方库的遗留代码，移动操作里偷偷做了深拷贝

举个例子，你想想看：

class FileHandle {
public:
    FileHandle(FileHandle&& other) noexcept(false) {
        // 这里试图打开一个新文件描述符
        fd_ = open(other.path_, O_RDONLY);
        if (fd_ == -1) {
            throw std::runtime_error("open failed");
        }
        other.fd_ = -1;
    }
private:
    int fd_;
    std::string path_;
};

这个移动构造函数，说白了就是在做「拷贝+销毁」的事。它完全违背了移动语义的初衷——轻量、快速、不失败。

22.3 异常发生时，回退机制怎么工作？

假设你有一个 std::vector<MyType>，当它扩容时，内部会做这么几件事：

分配新内存
把旧元素移动到新内存
销毁旧元素
释放旧内存

如果第2步移动操作抛异常了，怎么办？

标准库的保证是：如果移动操作是 noexcept 的，容器会直接使用移动；否则，容器会退回到拷贝操作。

但这里有个更微妙的问题——如果移动操作不是 noexcept 的，但实际也没抛异常，那容器还是会选择拷贝。这就是为什么我建议你：能加 noexcept 就加，别犹豫。

小技巧：如果你不确定移动操作是否真的不抛异常，可以用 static_assert 在编译期检查：

static_assert(std::is_nothrow_move_constructible_v<MyType>,
              "MyType 的移动构造必须不抛异常");

22.4 标准库的回退策略：强异常安全保证

标准库容器（如 std::vector、std::deque）在扩容时，会遵循一个重要的原则：强异常安全保证。意思是，如果操作过程中抛出了异常，容器的状态必须和操作前完全一致。

具体来说：

如果移动操作是 noexcept 的，容器用移动，速度快
如果移动操作可能抛异常，容器用拷贝，保证安全
如果拷贝也抛异常……那容器就保持原样，不改变

这个回退机制，说白了就是「宁可慢，不能乱」。

我曾经在一个项目中，把一个类的移动构造函数忘了加 noexcept，结果性能测试发现 std::vector 的插入操作比预期慢了3倍。查了半天才发现，每次扩容都在做拷贝，而不是移动。加上 noexcept 后，性能立刻恢复正常。

22.5 自定义回退机制：自己动手

有时候，你确实无法保证移动操作不抛异常。比如你要移动一个包含数据库连接的对象，移动过程中需要提交事务——这就有可能失败。

这种情况下，你可以自己实现回退机制：

class Transaction {
public:
    Transaction(Transaction&& other) noexcept(false) {
        // 尝试移动资源
        if (!other.TryMoveTo(*this)) {
            // 移动失败，回退到空状态
            // 但保证当前对象处于有效状态
            throw std::runtime_error("move failed");
        }
    }

    // 提供一个不抛异常的备用移动方式
    Transaction& operator=(Transaction&& other) noexcept {
        // 如果移动失败，至少保证当前对象状态不变
        if (this != &other) {
            // 先保存当前状态
            auto backup = std::move(*this);
            try {
                // 尝试移动
                // ...
            } catch (...) {
                // 回退到备份状态
                *this = std::move(backup);
                throw;
            }
        }
        return *this;
    }
};

嗯，这里要注意：上面的代码只是一个示例思路。实际项目中，我建议你尽量把移动操作设计成不抛异常的。如果实在做不到，那就用拷贝代替移动，别硬撑。

22.6 避坑指南：我踩过的几个坑

这些年下来，我在移动语义和异常这个交叉点上踩过不少坑。分享几个典型的：

坑1：移动后源对象的状态

我曾经写过一个类，移动构造函数里把源对象的指针置空了，但没处理异常情况。结果移动到一半抛异常了，源对象的状态既不是完整的，也不是空的——成了一个「僵尸对象」。后来我养成了一个习惯：在移动操作中，先完成所有可能抛异常的操作，最后再修改源对象的状态。

坑2：忘记给移动操作加 noexcept

这个前面提过了。标准库的 std::vector 会通过 std::move_if_noexcept 来判断用移动还是拷贝。如果你忘了加 noexcept，即使你的移动操作实际上不抛异常，标准库也会选择拷贝。性能损失是实打实的。

坑3：移动赋值运算符的自我赋值

自我赋值在移动语义中很少见，但一旦发生，配合异常处理就很容易出问题。我建议你在移动赋值运算符的开头加一个 if (this != &other) 检查，虽然大部分情况下用不到，但能防止一些诡异的bug。

22.7 知识体系图：移动语义与异常的核心逻辑

下面这张图，帮你理清移动操作与异常之间的决策流程：

这张图的核心逻辑其实很简单：noexcept 决定策略，异常决定回退。你只要记住，移动操作尽量加 noexcept，就能避免大部分问题。

22.8 总结

移动语义和异常处理，说白了就是「性能」和「安全」之间的权衡。我个人习惯是：

所有移动操作都加上 noexcept，除非有非常特殊的理由不这么做
如果移动操作确实可能抛异常，那就用拷贝代替移动，别想着在移动中做复杂的回退
使用 std::move_if_noexcept 来让标准库自动选择最优策略

嗯，最后再啰嗦一句：移动操作不抛异常，不是C++标准的要求，但它是优秀C++代码的标配。你写代码的时候多花一分钟加个 noexcept，可能就帮未来的自己省下一天调试时间。

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