在C++中，构造函数肩负着初始化对象成员的责任。与普通函数不同，一旦构造过程抛出异常，编译器不会调用该对象的析构函数，这就导致在异常抛出前已经手动分配的资源无法自动释放。理解这一机制并采用合理的编码手段，是编写健壮C++程序的基本要求。
为什么构造函数抛异常会带来风险
当构造函数执行到某一步抛出异常时，C++标准规定：只有那些已经构造完成的基类子对象和成员子对象会被析构，而当前正在构造的对象的析构函数本身不会被执行。这意味着如果你在构造函数体内用裸指针申请了内存，并且在申请之后、构造函数结束之前抛出了异常，这块内存就会泄漏。
下面这段代码展示了典型的问题场景。我们在构造函数中依次分配了两个资源，第二个分配后抛出了异常，但第一个资源因为没有智能管理且析构函数不会被调用，从而泄漏。
#include <iostream>
#include <stdexcept>
class BadExample {
public:
BadExample() {
p1 = new int[100]; // 分配成功
throw std::runtime_error("构造失败");
p2 = new int[200]; // 不会执行
}
~BadExample() {
delete[] p1;
delete[] p2;
}
private:
int* p1;
int* p2;
};
int main() {
try {
BadExample obj;
} catch (const std::exception& e) {
std::cout << e.what() << std::endl;
}
return 0;
}
上述代码运行后，p1指向的数组永远不会被释放。很多初学者误以为析构函数一定会执行，这是错误的。只有对象完全构造成功后，生命周期结束时才会调用析构函数。
使用RAII与智能指针避免泄漏
解决该问题最推荐的方式是优先使用标准库提供的智能指针，如std::unique_ptr和std::shared_ptr。它们本身也是对象，在构造函数的成员初始化阶段或体内被构造，如果后续发生异常，已经构造好的智能指针成员会自动析构并释放所管理的资源。
下面的代码改用std::unique_ptr管理内存，即使构造函数后续抛异常，p1也会被正确释放，因为unique_ptr的析构函数会在栈展开时被调用。
#include <iostream>
#include <memory>
#include <stdexcept>
class GoodExample {
public:
GoodExample() : p1(std::make_unique<int[]>(100)) {
throw std::runtime_error("构造失败但资源安全");
}
private:
std::unique_ptr<int[]> p1;
};
int main() {
try {
GoodExample obj;
} catch (const std::exception& e) {
std::cout << e.what() << std::endl;
}
return 0;
}
这种方式体现了RAII（资源获取即初始化）的核心思想：将资源绑定到对象生命周期上。只要资源管理者本身具备正确的析构行为，异常导致的栈展开就能安全回收资源，不需要在构造函数中写复杂的清理逻辑。
在构造函数内用try-catch主动回滚
有时资源类型不是内存，而是文件句柄、套接字或者第三方库对象，它们可能没有对应的智能包装类。此时可以在构造函数体内使用try-catch块，捕获异常后手动释放已获取的资源，再重新抛出或处理错误状态。
以下示例展示了一个需要打开文件并在失败时关闭句柄的写法：
#include <iostream>
#include <fstream>
#include <stdexcept>
class FileWrapper {
public:
FileWrapper(const char* name) {
try {
file.open(name);
if (!file.is_open()) {
throw std::runtime_error("无法打开文件");
}
// 其他可能抛异常的初始化
throw std::runtime_error("后续初始化失败");
} catch (...) {
if (file.is_open()) {
file.close();
}
throw; // 重新抛出，让调用者知道构造失败
}
}
private:
std::fstream file;
};
int main() {
try {
FileWrapper fw("test.txt");
} catch (const std::exception& e) {
std::cout << e.what() << std::endl;
}
return 0;
}
这种写法的优点是逻辑清晰，在catch块中集中处理回滚。缺点是当资源种类变多时代码会变得冗长。因此通常建议先封装资源为RAII类，再在构造函数中组合使用。
将可能失败的操作移出构造函数
另一种被广泛采用的策略是让构造函数尽量只做不会失败或极少失败的简单初始化，把可能抛异常的步骤放到独立的init()函数中，或者使用工厂函数创建对象。这样调用者可以明确感知错误，而不依赖异常机制。
下面用工厂函数示范如何返回创建结果：
#include <iostream>
#include <memory>
#include <stdexcept>
class Worker {
public:
static std::unique_ptr<Worker> create() {
auto w = std::unique_ptr<Worker>(new Worker());
try {
w->init();
} catch (...) {
return nullptr;
}
return w;
}
void init() {
throw std::runtime_error("初始化失败");
}
private:
Worker() = default;
};
int main() {
auto w = Worker::create();
if (!w) {
std::cout << "创建失败" << std::endl;
}
return 0;
}
工厂函数将构造与初始化分离，既避免了构造函数异常带来的对象半初始化问题，也方便返回空指针或错误码。对于大型系统，这种显式错误处理往往比依赖异常更可控。
总结与实践建议
处理C++构造函数中的异常，核心原则是不要依赖析构函数来做构造期资源的清理，因为析构根本不会被调用。优先采用智能指针和RAII包装，让编译器自动管理生命周期；对于特殊资源，用try-catch在构造函数内回滚；在更复杂场景下，把失败风险移出构造函数。
日常编码时，应养成在成员初始化列表中完成资源获取的习惯，并尽量减少构造函数体内的复杂逻辑。这样即使发生异常，也能保证程序不泄漏资源、不出现野指针，从而提升整体的异常安全性。