自定义删除器不应抛出异常，因析构过程抛异常会触发std::terminate导致程序崩溃；正确做法是将删除器声明为noexcept，并在内部用try-catch捕获并处理所有异常，确保资源释放操作安全可靠。
当我们在C++中使用智能指针，比如
std::unique_ptr或
std::shared_ptr，并为其提供自定义删除器时，一个非常关键但又容易被忽视的问题就是：如何处理这个删除器内部可能抛出的异常。我的核心观点是，最安全、最符合C++惯例的做法是，确保你的自定义删除器永远不会抛出任何异常。 如果删除器中涉及的操作确实可能失败并产生异常，那么这些异常必须在删除器内部被捕获并妥善处理，例如记录到日志，但绝不能让它们传播出删除器的边界。否则，你将面临未定义行为，甚至可能导致程序非正常终止。
这听起来可能有点绝对，但它背后有非常扎实的理由。C++标准对析构函数（以及智能指针删除器这种在对象生命周期结束时被调用的机制）有着明确的期待：它们应该是
noexcept的。这意味着，如果一个析构函数，或者一个被显式声明为
noexcept的函数（我们的删除器如果被正确设计，就应该如此），抛出了异常，C++运行时会立即调用
std::terminate。这可不是我们乐意见到的，它会导致程序直接崩溃，而且往往因为没有正常的栈回溯而难以调试。
设想一下，你的智能指针在析构时，尝试释放一个资源，而这个释放操作因为某些外部因素（比如文件句柄已失效、网络连接已断开，或者底层API本身就设计得会抛异常）抛出了一个异常。如果这个异常没有在删除器内部被捕获，它就会从一个析构函数的调用链中逃逸出来。此时，C++运行时环境会陷入一个非常尴尬的境地：在一个对象正在被销毁的过程中又出现了新的异常，这与异常安全的基本原则是冲突的。它无法保证程序的稳定状态，所以最直接、最保守的反应就是终止程序，以避免更深层次的问题。
因此，我个人在实践中，几乎都会将自定义删除器视为一个“无条件成功”的操作。如果删除器确实需要执行一些复杂且可能失败的逻辑，那么这些逻辑必须被包装在一个
try-catch块中。在
catch块里，你可以选择记录错误日志，或者更新一些错误状态标志，但关键在于——你不能重新抛出异常。这是为了保证智能指针在销毁时的行为是可预测且安全的。
立即学习“C++免费学习笔记（深入）”；
#include <iostream>
#include <memory>
#include <stdexcept>
#include <cstdio> // For FILE* operations
// 模拟一个可能抛出异常的资源释放函数
// 比如关闭一个文件，但文件句柄可能无效或操作失败
void close_file_resource(FILE* fp) {
if (fp == nullptr) {
// 实际场景中，nullptr通常不会导致抛异常，但为了演示可以模拟
throw std::runtime_error("Attempted to close a null file pointer.");
}
std::cout << "Attempting to close file pointer: " << fp << std::endl;
if (fclose(fp) != 0) {
// fclose 失败会返回 EOF，但通常不会抛C++异常。
// 这里为了演示“可能抛出异常的操作”而模拟抛出。
throw std::runtime_error("Failed to close file resource properly.");
}
std::cout << "File pointer " << fp << " closed successfully." << std::endl;
}
// 错误的自定义删除器示例：会直接抛出异常
struct BadFileDeleter {
void operator()(FILE* fp) const {
std::cout << "BadFileDeleter: Executing..." << std::endl;
close_file_resource(fp); // 这里可能会抛出异常
}
};
// 正确的自定义删除器示例：内部处理异常，并声明noexcept
struct SafeFileDeleter {
void operator()(FILE* fp) const noexcept { // 明确声明noexcept
std::cout << "SafeFileDeleter: Executing..." << std::endl;
try {
close_file_resource(fp);
} catch (const std::exception& e) {
// 捕获并处理异常，例如记录日志
std::cerr << "ERROR: SafeFileDeleter caught exception for file " << fp
<< ": " << e.what() << std::endl;
// 关键：不要重新抛出异常
} catch (...) {
std::cerr << "ERROR: SafeFileDeleter caught unknown exception for file " << fp << std::endl;
}
}
};
// int main() {
// std::cout << "--- Testing BadFileDeleter (may terminate) ---" << std::endl;
// try {
// // 模拟一个文件指针
// FILE* f1 = fopen("test1.txt", "w");
// if (f1) {
// std::unique_ptr<FILE, BadFileDeleter> bad_file_ptr(f1, BadFileDeleter{});
// // bad_file_ptr 在离开作用域时析构，如果 close_file_resource 抛异常，程序会 terminate
// // 我们可以通过将 f1 设为 nullptr 来模拟抛异常
// // bad_file_ptr.release(); // 避免实际关闭，让它在析构时遇到 nullptr
// }
// // 为了演示异常，我们故意创建一个会抛异常的场景
// std::unique_ptr<FILE, BadFileDeleter> bad_file_ptr_null(nullptr, BadFileDeleter{});
// } catch (const std::exception& e) {
// std::cerr << "Caught exception in main for BadFileDeleter: " << e.what() << std::endl;
// }
// // 注意：如果 BadFileDeleter 真的抛出异常，程序可能在这里之前就已经终止了
// std::cout << "--- BadFileDeleter test finished (or terminated) ---" << std::endl;
//
// std::cout << "\n--- Testing SafeFileDeleter (should not terminate) ---" << std::endl;
// try {
// FILE* f2 = fopen("test2.txt", "w");
// if (f2) {
// std::unique_ptr<FILE, SafeFileDeleter> safe_file_ptr(f2, SafeFileDeleter{});
// // safe_file_ptr 析构时，即使 close_file_resource 抛异常，也会被内部处理，程序继续运行
// }
// // 故意创建一个会抛异常的场景
// std::unique_ptr<FILE, SafeFileDeleter> safe_file_ptr_null(nullptr, SafeFileDeleter{});
// } catch (const std::exception& e) {
// std::cerr << "Caught exception in main for SafeFileDeleter: " << e.what() << std::endl;
// }
// std::cout << "--- SafeFileDeleter test finished ---" << std::endl;
// return 0;
// }为什么智能指针的自定义删除器不应该抛出异常？
这个问题是理解智能指针异常安全性的基石。智能指针的自定义删除器，其核心职责是在所管理的对象生命周期结束时，执行必要的资源清理工作。从语义上讲，这与C++对象的析构函数行为非常相似。而C++标准对析构函数有一个非常重要的约定：它们通常应该是
noexcept的。这意味着，一个析构函数如果抛出异常并允许它传播出去，会导致未定义行为，最常见的结果就是程序调用
std::terminate并崩溃。
具体来说，当一个异常正在传播（即已经有一个异常被抛出，但尚未被捕获）时，如果此时又有另一个析构函数被调用，并且这个析构函数也抛出了异常，C++标准库会立即调用
std::terminate。这被称为“双重异常”（double exception）问题。即使当前没有异常在传播，一个
noexcept的函数（包括隐式
noexcept的析构函数，或者我们明确标记为
noexcept的删除器）如果抛出异常，同样会直接导致
std::terminate。
所以，让删除器抛出异常，不仅违反了C++关于析构函数异常安全的基本原则，还会让你的程序变得极其脆弱和不可预测。我个人在开发中，几乎都会把删除器设计成
noexcept的，这不仅仅是遵守规范，更是为了避免那些难以追踪的运行时崩溃。你肯定不希望你的程序在释放资源的时候，因为一个清理失败而直接崩溃，而不是优雅地记录错误并继续运行。
如果自定义删除器必须执行可能抛出异常的操作，我们应该如何处理？
现实世界并非总是理想的，有时你确实需要在一个删除器中调用一个第三方库函数，或者一个你无法控制的API，而这些函数就是被设计成可能抛出异常的。在这种“必须”执行可能抛出异常操作的情况下，我们的策略就变成了“内部消化”异常。
最直接的方法就是使用
try-catch块将所有可能抛出异常的代码包裹起来。在
catch块中，你可以选择记录下错误信息（这是最常见的做法），或者更新一些内部的错误状态标志。关键是，你不能在
catch块中再次抛出异常。
// 示例：一个处理异常的删除器
struct NetworkConnectionDeleter {
void operator()(void* connection_handle) const noexcept {
try {
// 假设这个函数可能因为网络问题而抛出异常
disconnect_network_resource(connection_handle);
} catch (const std::exception& e) {
// 记录错误日志，但不要重新抛出
std::cerr << "Error disconnecting network resource " << connection_handle
<< ": " << e.what() << std::endl;
} catch (...) {
// 捕获所有其他未知异常
std::cerr << "Unknown error disconnecting network resource "
<< connection_handle << std::endl;
}
}
// 假设的外部函数，可能抛出异常
void disconnect_network_resource(void* handle) const {
if (handle == nullptr) {
throw std::runtime_error("Invalid network handle.");
}
// 模拟网络断开操作，可能失败
bool success = (reinterpret_cast<long>(handle) % 2 == 0); // 随机失败
if (!success) {
throw std::runtime_error("Failed to disconnect due to network issue.");
}
std::cout << "Network connection " << handle << " disconnected." << std::endl;
}
};
// 使用示例
// int main() {
// void* conn_handle1 = (void*)0x100; // 模拟一个有效的句柄
// std::unique_ptr<void, NetworkConnectionDeleter> conn_ptr1(conn_handle1, NetworkConnectionDeleter{});
// // conn_ptr1 析构时，如果 disconnect_network_resource 抛异常，会被内部处理
//
// void* conn_handle2 = (void*)0x101; // 模拟另一个句柄，可能导致失败
// std::unique_ptr<void, NetworkConnectionDeleter> conn_ptr2(conn_handle2, NetworkConnectionDeleter{});
// return 0;
// }除了内部
try-catch，你还可以考虑在智能指针的生命周期结束 之前，就主动地、显式地执行那些可能抛出异常的清理操作。例如，如果你有一个文件句柄，并且关闭文件可能失败，你可以在智能指针即将被销毁之前，调用一个独立的
close_file_safely()函数，该函数负责处理异常，并确保文件被关闭。如果这个函数成功，你再将智能指针的原始指针
release()掉，这样删除器就什么都不用做了。但这会增加代码的复杂性，并且失去了智能指针自动管理的便利。我发现很多时候，如果删除器变得复杂到需要考虑异常，那往往意味着我们把不该放进去的逻辑塞进去了。删除器就该是“终结者”，而不是“错误报告员”。
如何设计一个健壮的自定义删除器来规避异常问题？
设计一个健壮的自定义删除器，其核心思想是“防御性编程”和“最小化职责”。
明确声明
noexcept
： 这是第一步，也是最重要的一步。通过在删除器函数签名后加上noexcept
关键字，你是在向编译器和读者保证，这个函数不会抛出异常。如果它真的抛出了，编译器会直接调用std::terminate
，这虽然是崩溃，但至少是可预测的崩溃，避免了更隐蔽的未定义行为。保持删除器逻辑的简单性： 删除器的主要任务就是释放资源，它不应该包含复杂的业务逻辑、状态管理或者与其他组件的交互。越简单，出错的可能性越小，需要处理异常的情况也就越少。例如，一个负责
delete
内存的删除器，或者一个负责fclose
文件句柄的删除器，通常都非常简单。内部消化所有潜在异常： 如果确实无法避免调用可能抛出异常的函数，那么所有这些调用都必须被包裹在
try-catch
块中。在catch
块里，记录错误是最好的做法。你可以使用日志系统、或者std::cerr
输出错误信息。-
考虑资源本身的RAII封装： 有时候，与其在智能指针的删除器里处理复杂逻辑，不如将资源本身封装在一个更小的RAII（Resource Acquisition Is Initialization）类中。这个小RAII类负责资源的构造、销毁以及所有可能抛出异常的中间操作。这样，智能指针的删除器就只需要简单地
delete
这个小RAII类的实例，而所有异常处理的复杂性都被封装在那个RAII类内部了。// 示例：一个更健壮的资源封装 class FileHandle { private: FILE* fp_; public: explicit FileHandle(const char* filename, const char* mode) : fp_(nullptr) { fp_ = fopen(filename, mode); if (!fp_) { throw std::runtime_error("Failed to open file: " + std::string(filename)); } std::cout << "File " << filename << " opened. Handle: " << fp_ << std::endl; } // 析构函数处理关闭，内部捕获异常 ~FileHandle() noexcept { if (fp_) { std::cout << "FileHandle destructor:
