成员析构函数可抛异常时派生类析构编译错误的最优处理方案

报错根因 #

C++11及之后的标准中，未显式声明异常规范的虚析构函数会隐式声明为noexcept(true)。你的基类A的虚析构未显式指定异常规则，因此默认不允许抛出异常；而子类B因为持有析构函数显式声明为noexcept(false)的MyObject成员，B的默认析构函数会隐式声明为noexcept(false)，重写虚函数时异常规范比基类宽松，违反语法规则，因此编译报错。

最优处理方案 #

按适用场景优先级从高到低排序：

• 场景1：基类A可以修改
  最直接的方案是给基类A的虚析构显式声明noexcept(false)，所有子类都不需要额外修改代码，天然符合异常规范要求：

  class A {
  public:
      A() {}
      virtual ~A() noexcept(false) {}
  };
  

• 场景2：基类不可修改，需要主动处理MyObject销毁时的异常
  不要用裸指针，推荐使用带自定义删除器的智能指针封装MyObject的生命周期，既保留RAII的资源安全保证，又可以把可抛的销毁逻辑移到普通成员函数中：

  #include <memory>
  
  struct MyObjectDeleter {
      void operator()(MyObject* ptr) const {
          if (!ptr) return;
          try {
              delete ptr;
          } catch (...) {
              // 兜底逻辑：记录日志、吞掉异常，绝对不能让异常抛到析构函数外
          }
      }
  };
  
  class B : public A {
  public:
      B() : A(), _object(std::make_unique<MyObject>()) {}
      ~B() override = default; // 隐式noexcept(true)，符合基类要求
  
      // 主动销毁接口，上层可调用并处理抛出的异常
      void Close() {
          _object.reset();
      }
  private:
      std::unique_ptr<MyObject, MyObjectDeleter> _object;
  };
  

  这种方案的优势：
  • 不需要手动管理内存，就算上层忘记调用Close，智能指针的兜底删除逻辑也会保证资源不泄漏，且不会抛出异常触发程序终止
  • 主动调用Close时如果MyObject析构抛异常，可以正常向上层抛出，符合业务处理需求
• 场景3：不需要对外暴露销毁逻辑，仅需内部处理异常
  可以直接在B的析构函数中手动销毁MyObject并捕获所有异常，不需要额外加Close接口：

  #include <memory>
  
  class B : public A {
  public:
      B() : A() {
          new (&_object_storage) MyObject();
      }
      ~B() override {
          try {
              std::destroy_at(reinterpret_cast<MyObject*>(&_object_storage));
          } catch (...) {
              // 内部处理异常，不向外抛出
          }
      }
  private:
      std::aligned_storage_t<sizeof(MyObject), alignof(MyObject)> _object_storage;
  };
  

注意事项 #

C++标准明确不推荐析构函数向外抛出异常：如果析构函数在栈展开（异常触发的资源清理流程）过程中抛出异常，会直接调用std::terminate终止程序。因此不管用哪种方案，都要保证析构函数最终不会向外抛异常，所有需要上层处理的销毁异常都放到普通成员函数中执行。

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