C.36: A destructor may not fail
Destructor should not fail
Reason (reason)
In general we do not know how to write error-free code if a destructor should fail. The standard library requires that all classes it deals with have destructors that do not exit by throwing.
If the destructor will fail, we usually do not know how to write the code without errors. The standard library which handles all required class destructor are not thrown.
Example (Example)
class X {
public:
~X() noexcept;
// ...
};
X::~X() noexcept {
// ...
if (cannot_release_a_resource) terminate();
// ...
}
Swipe left or right to see more
Note (Note)
Many have tried to devise a fool-proof scheme for dealing with failure in destructors. None have succeeded to come up with a general scheme. This can be a real practical problem: For example, what about a socket that won't close? The writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. See discussion. To make the problem worse, many "close/release" operations are not retryable. If at all possible, consider failure to close/cleanup a fundamental design error and terminate.
The method of the invention for a reliable destructor error processing, various attempts have been made. No method developed into a common practice. This is a real practical problem: for example, how to do when the socket can not be closed? Writers destructor destructor do not know because of what is called, but not by throwing an exception to reject this action. See the discussion (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Sd-never-fail). More seriously, a lot of "off / release" operation is not retried. If possible, will be closed / error occurred when released as a fundamental design error and terminates execution.
Note (Note)
Declare a destructor noexcept. That will ensure that it either completes normally or terminate the program.
The destructor is defined as noexcept. This will ensure that the end of either normal destructor, or terminate the program.
Note (Note)
If a resource cannot be released and the program may not fail, try to signal the failure to the rest of the system somehow (maybe even by modifying some global state and hope something will notice and be able to take care of the problem). Be fully aware that this technique is special-purpose and error-prone. Consider the "my connection will not close" example. Probably there is a problem at the other end of the connection and only a piece of code responsible for both ends of the connection can properly handle the problem. The destructor could send a message (somehow) to the responsible part of the system, consider that to have closed the connection, and return normally.
If the resource can not be released and the program may not fail, in some way (even some global variables can be modified and hope that some programs will pay attention to and deal with the problem) send wrong signals to other parts of the program. We need to be fully aware of the special purpose of this technology, but also prone to error. Consider the example "My link does not close." There may be a problem at the other end, and both ends of the link for it, there is only a piece of code bears the responsibility to deal with this issue properly. Destructor can (in some way) the system responsible for handling errors in part to send a message, the same time that we have closed the link and return to the right.
Note (Note)
If a destructor uses operations that may fail, it can catch exceptions and in some cases still complete successfully (e.g., by using a different clean-up mechanism from the one that threw an exception).
If the destructor using the operation may fail, and it can catch exceptions themselves and in some cases still successfully concluded (for example, using a different clearance mechanisms other than an exception is thrown).
Enforcement (Suggestions)
(Simple) A destructor should be declared noexcept if it could throw.
(Simple) if possible exception is thrown, then the destructor should be declared as noexcept.
Translator's Note: Statement noexcept, the compiler will not generate abnormal delivery mechanism, then once the exception is thrown, the program will directly terminated.
Description link
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c36-a-destructor-may-not-fail
I think this article helpful? Welcome thumbs up and share it with more people.
Read more updated articles, please pay attention to micro-channel public number of object-oriented thinking []
