容器中能否使用可抛出异常的移动操作？

Great question—this cuts straight to the tradeoffs between exception safety, performance, and practicality in C++ container design. Let’s unpack your doubts step by step:

First: The Core Issue Isn’t "Impossible Recovery"—It’s Reliable Recovery #

Your initial point was right: if a move operation fails, recovering the original object isn’t always feasible. But even in cases where you think recovery might work, there are critical pitfalls:

• Partial state modification: Many move operations work by first transferring resources from the original object to the new one, then cleaning up the original. For example:

  class Buffer {
  public:
      Buffer(Buffer&& other) 
          : data(other.data), size(other.size) {
          // We've already taken the original's data
          other.data = nullptr;
          other.size = 0;
  
          // If this allocation fails, the original object is already emptied!
          if (some_resource_allocation_fails()) {
              throw std::bad_alloc();
          }
      }
  private:
      char* data;
      size_t size;
  };
  

  Here, if an exception is thrown after we’ve modified the original object, there’s no way to get its original state back. The data pointer is already null, and we can’t magically restore it.

• No compiler-level undo: Compilers can’t automatically reverse custom move logic. If your move operation does something non-trivial—like updating external counters, modifying file handles, or altering shared state—there’s no way for the compiler to know how to "undo" those changes. Only you could write that recovery logic, which adds massive complexity and isn’t feasible for general-purpose containers.

Second: Container Exception Safety Guarantees #

C++ containers are required to provide strong exception safety for most operations: if an exception is thrown during an operation (like resize, push_back, or insert), the container must be restored to its exact state before the operation started.

For example, when a vector needs to resize, it:

1. Allocates new memory
2. Moves existing elements to the new memory
3. Frees the old memory

If step 2 throws an exception, the vector needs to roll back: move all already-transferred elements back to the old memory, then deallocate the new memory. But if the move operation itself can throw, this rollback could also throw—leading to an unrecoverable state where the container is half-moved, half-not.

Requiring move operations to be noexcept eliminates this risk: if moves can’t throw, the container can safely complete the transfer, or abandon it entirely without worrying about partial failures.

Third: Swap Isn’t a Universal Fix #

You mentioned using swap as a workaround, and while swap is typically noexcept (since it just swaps resource handles), it has limitations:

• Swap is bidirectional: it exchanges state between two objects, whereas containers need a one-way transfer (move elements to a new location, then destroy the old ones).
• Swap doesn’t handle custom move logic: if your object’s move operation includes additional work (like updating a reference count or logging), swap won’t execute that logic—it just swaps raw resources.

Are You Overcomplicating Things? #

Not at all—you’re asking exactly the right questions. The requirement for noexcept move operations isn’t about theoretical impossibility of recovery; it’s about practicality, consistency, and guaranteeing that containers can maintain their invariants even when things go wrong.

While there are niche cases where a throwing move operation could be made safe with careful coding, these are exceptions (pun intended) rather than the rule. For general-purpose containers, relying on noexcept moves is the only way to deliver the strong exception safety that C++ developers expect.

内容的提问来源于stack exchange，提问作者Adrian