期望程序员在引发异常后删除对象是否合理?

Is it reasonable to expect a programmer to delete an object after an exception is thrown?

本文关键字：是否 对象 删除 程序员 异常 期望      更新时间：2023-10-16

>我有一个结构如下的类：

class Server
{
    private:
    SOCKET listener;
    public:
    Server(char const * const address, unsigned short int port);
    ~Server();
    void Start();
};

如果 Start 方法在调用 CreateIoCompletionPort 或 listen 期间引发异常，是否有替代方法可以依赖库的用户来delete对象？

我知道有点主观，但是对于这种情况有最佳实践吗？

我希望避免重复清理代码，并可能导致双重释放资源的问题，以及还必须跟踪已清理和未清理的内容的复杂性。

编辑

为了澄清提出的一些问题，我指的是我的代码用户何时将创建Server类的实例。我正在尝试决定是否应该采取保护类在由于Start中遇到异常而处于无效状态时免于执行的路线。如果 Start 方法由于某些问题而失败，则这是一个不可恢复的错误，并且类处于错误状态，无法继续操作。这将类似于配置错误或系统级错误，阻止Start成功，但同时使SOCKET处于无法在不关闭和创建新套接字的情况下还原的状态。

期望程序员记住删除他分配的所有内容是完全不合理的，尤其是在存在异常的情况下：一个人可以记住多少是有限制的，在一个足够大的系统中，你很快就会遇到这个限制。

但是，删除所有内容是他必须做的，以避免内存泄漏。为了取得任何程度的成功，程序员需要做两件事：

  • 遵循防御性编码做法 - 首选在自动存储中分配的对象而不是指针。当必须动态分配对象时，请使用智能指针。坚持 RAII 技术。
  • 编写详尽的单元测试，并分析内存泄漏 - 使用内存探查器可帮助您发现否则难以发现的泄漏。
第一部分是

预防;第二部分是"安全网"。如果你在使用智能指针和运行单元测试方面有纪律，那么你的代码在基本级别将是异常安全的（即它将提供无泄漏保证）。您可以更进一步，预先进行分配，并且仅在所有分配都成功实现事务语义以实现强大的异常安全性时才更改状态。

相关文章：