Page History

Under certain circumstances, terminating a destructor, operator delete, or operator delete[] by throwing an exception can trigger undefined behavior.

For instance, the C++ Standard, [basic.stc.dynamic.deallocation], paragraph 3 [ISO/IEC 14882-2014], states in part, states the following:

If a deallocation function terminates by throwing an exception, the behavior is undefined.

In these situations, the function must logically be declared noexcept because throwing an exception from the function can never have well-defined behavior. The C++ Standard, [except.spec], paragraph 15, states the following:

A deallocation function with no explicit exception-specification is treated as if it were specified with noexcept(true).

...

Object destructors are likely to be called during stack unwinding as a result of an exception being thrown. If the destructor itself throws an exception, having been called as the result of an exception being thrown, then the function std::terminate() is called with the default effect of calling std::abort() [ISO/IEC 14882-2014]. When std::abort() is called, no further objects are destroyed, resulting in an indeterminate program state and undefined behavior. Do not terminate a destructor by throwing an exception. 

The C++ Standard, [class.dtor], paragraph 3, states [ISO/IEC 14882-2014] the following:

A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same exception-specification as an implicit declaration.

...

Noncompliant Code Example (function-try-block)

In this noncompliant This noncompliant code example, the SomeClass destructor attempts to handle exceptions thrown from the destructor of the bad_member subobject by absorbing them. However, the C++ Standard, [except.handle], paragraph 15 [ISO/IEC 14882-2014], states in part:

The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor.

Consequently, the caught exception will inevitably escape from the SomeClass destructor because it is implicitly rethrown when control reaches the end of the function-try-block handleras well as the following compliant solution, presumes the existence of a Bad class with a destructor that can throw. Although the class violates this rule, it is presumed that the class cannot be modified to comply with this rule.

// Assume that this class is provided by a 3rd party and it is not something
// that can be modified by the user.
class Bad {
  ~Bad() noexcept(false);
};

To safely use the Bad class, the SomeClass destructor attempts to handle exceptions thrown from the Bad destructor by absorbing them.

class SomeClass {
  Bad#include <stdexcept>
 
class SomeClass {
  class Bad {
    bool has_error() const;
  public:
    ~Bad() noexcept(false) {
      if (has_error()) {
        throw std::logic_error("Something bad");
      }
    }
  } bad_member;

public:
  ~SomeClass()
  try {
    // ...
  } catch(...) {
    // Handle the exception thrown from the Bad destructor.
  }
};

However, the C++ Standard, [except.handle], paragraph 15 [ISO/IEC 14882-2014], in part, states the following:

...

The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor.

Consequently, the caught exception will inevitably escape from the SomeClass destructor because it is implicitly rethrown when control reaches the end of the function-try-block handler.

Compliant Solution

A destructor should perform the same way whether or not there is an active exception. Typically, this means that it should invoke only operations that do not throw exceptions, or it should handle all exceptions and not rethrow them (even implicitly). In this compliant solution, all exceptions are caught in the function-try-block and the exception will not be rethrown because control does not reach This compliant solution differs from the previous noncompliant code example by having an explicit return statement in the SomeClass destructor. This statement prevents control from reaching the end of the exception handler due to the explicit return statement. This . Consequently, this handler will catch the exception thrown by Bad::~Bad() when bad_member is destroyed, and it . It will also catch any exceptions thrown within the the compound statement of the function-try-block, but the SomeClass destructor will not terminate by throwing an exception.

#include <stdexcept>
 
class SomeClass {
  class Bad {
    bool has_error() const;
  public:
    ~Bad() noexcept(false) {
      if (has_error()) {
        throw std::logic_error("Something bad");
      }
    }
  } bad_member;
public:

  ~SomeClass()
  try {
    // ...
  } catch(...) {
    // Catch exceptions thrown from noncompliant destructors of
    // member objects or base class subobjects.

    // NOTE: Returning from Flowing off the end of a destructor function-try-block causes
    // the caught exception to be implicitly rethrown, but an explicit
    // explicit return statement will prevent that from happening.
    return;
  }
};

...

#include <stdexcept>
 
bool perform_dealloc(void *);
 
void operator delete(void *ptr) noexcept(false) {
  if (perform_dealloc(ptr)) {
    throw std::logic_error("Something bad");
  }
}

Compliant Solution

The compliant solution does not throw exceptions in the event the deallocation fails but instead fails as gracefully as possible:.

#include <cstdlib>
#include <stdexcept>
 
bool perform_dealloc(void *);
void log_failure(const char *);
 
void operator delete(void *ptr) noexcept(true) {
  if (perform_dealloc(ptr)) {
    log_failure("Deallocation of pointer failed");
    std::exit(1); // Fail, but still call destructors
  }
}

...

Attempting to throw exceptions from destructors or deallocation functions can result in undefined behavior, leading to resource leaks or denial-of-service attacks.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified