C++如何在智能指针中处理自定义删除器异常-C++-PHP中文网

自定义删除器不应抛出异常，因析构过程抛异常会触发std::terminate导致程序崩溃；正确做法是将删除器声明为noexcept，并在内部用try-catch捕获并处理所有异常，确保资源释放操作安全可靠。

c++如何在智能指针中处理自定义删除器异常

当我们在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，而这些函数就是被设计成可能抛出异常的。在这种“必须”执行可能抛出异常操作的情况下，我们的策略就变成了“内部消化”异常。

硅基智能

基于Web3.0的元宇宙，去中心化的互联网，高质量、沉浸式元宇宙直播平台，用数字化重新定义直播

查看详情

最直接的方法就是使用

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:

登录后复制

以上就是C++如何在智能指针中处理自定义删除器异常的详细内容，更多请关注php中文网其它相关文章！