期望程序员在抛出异常后删除对象是否合理？(Is it reasonable to expect a programmer to delete an object after an exception

期望程序员在抛出异常后删除对象是否合理？(Is it reasonable to expect a programmer to delete an object after an exception is thrown?)

我的课程结构如下：

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处于无法关闭并创建新套接字时无法恢复的状态。

I have a class structured like this:

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

Is there an alternative to relying on the user of the library to delete the object if the Start method throws an exception during say a call to CreateIoCompletionPort or listen?

A little bit subjective I know, but is there a best practice for this kind of situation?

I wanted to avoid duplicating the cleanup code and potentially causing problems with double freeing resources and the added complexity of also having to track what is cleaned up and what is not.

EDIT

To clear up some of the questions asked, I am referring to when a user of my code will create an instance of the Server class. I am trying to decide whether or not I should go the route of protecting the class from executing when it's in an invalid state due to an exception being encountered within Start. If the Start method fails because of some issue, then it's an unrecoverable error and the class is in a bad state and cannot go any further. This would be something like a configuration error or a system level error that prevents Start from succeeding, but at the same time leaves the SOCKET in a state that can't be reverted without closing and creating a new socket.

最满意答案

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

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

遵循防御性编码实践 - 将自动存储中分配的对象更喜欢指针。 必须动态分配对象时，请使用智能指针。 坚持RAII技术。 编写详尽的单元测试，并对它们进行内存泄漏分析 - 使用内存分析器可以帮助您发现难以找到的泄漏。

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

It is entirely unreasonable to expect a programmer to remember deleting everything he allocates, especially in the presence of exceptions: there is a limit to how much a human being can keep in mind, and in a sufficiently large system you run against that limit pretty quickly.

However, deleting everything is what he must do in order to avoid memory leaks. To achieve any degree of success, programmers need to do two things:

Follow defensive coding practices - Prefer objects allocated in automated store to pointers. Use smart pointers when you must allocate objects dynamically. Adhere to RAII techniques. Write exhaustive unit tests, and profile them for memory leaks - Using memory profiler helps you spot leaks that are otherwise hard to find.

The first part is prevention; the second part is the "safety net". If you are disciplined about using smart pointers and running your unit tests, your code would be exception-safe at the basic level (i.e. it would provide a leak-free guarantee). You could go a step further, do your allocations upfront, and change state only when all allocations have succeeded to implement transactional semantic for strong exception safety.