DCL58-CPP. Destructors and deallocation functions must be declared noexcept

Under certain circumstances, terminating a function 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:

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:

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

As such, deallocation functions (object, array, and placement forms at either global or class scope) must not be declared noexcept(false) but may instead rely on the implicit noexcept(true) or declare noexcept explicitly.

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 indeterminate program state and undefined behavior.

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

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.

An implicit declaration of a destructor is considered to be noexcept(true) according to [except.spec], paragraph 14. As such, destructors must not be declared noexcept(false) but may instead rely on the implicit noexcept(true) or declare noexcept explicitly.

Note that any noexcept function that throws an exception violates ERR55-CPP. Honor exception specifications.

Noncompliant Code Example

In this noncompliant code example, the class destructor does not meet the implicit noexcept guarantee because it may throw an exception even if it was called as the result of an exception being thrown. Consequently, it is declared as noexcept(false) but still can trigger undefined behavior.

#include <stdexcept>
 
class S {
  bool should_throw() const;
 
public:
  ~S() noexcept(false) {
    // Normal processing
    if (should_throw()) {
      throw std::logic_error("Something bad");
    }
  }
};

Noncompliant Code Example (std::uncaught_exception())

Use of std::uncaught_exception() in the destructor solves the termination problem by avoiding the propagation of the exception if an existing exception is being processed, as demonstrated in this noncompliant code example. However, by circumventing normal destructor processing, this approach may keep the destructor from releasing important resources.

#include <exception>
#include <stdexcept>
 
class S {
  bool should_throw() const;
 
public:
  ~S() {
    // Normal processing
    if (should_throw() && !std::uncaught_exception()) {
      throw std::logic_error("Something bad");
    }
  }
};

Noncompliant Code Example (function-try-block)

In this noncompliant code example, class 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. Note that exceptions thrown from noncompliant destructors of class member objects or from base classes cannot be handled because they are implicitly rethrown when control reaches the end of the function-try-block handler, which is the only way to catch such exceptions.

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

  Bad bad_member;

public:
  ~SomeClass()
  try {
    // ...
  } catch(...) {
    // Attempt to handle exceptions thrown from Bad destructor.
  }
};

Compliant Code Example (try-block)

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. If necessary, a try-block may be used if the destructor must invoke an operation that may throw an exception.

struct SomeClass {
  ~SomeClass()
    try { // function-try-block
      try {   // Ordinary try-block
        // Clean up
      } catch(...) {
        // Catch and handle exceptions thrown during cleanup
      }
    } catch(...) {
      // Catch and log exceptions thrown from noncompliant
      // destructors of member objects or base class subobjects

      // NOTE: Returning from a destructor function-try-block
      // causes the caught exception to be implicitly rethrown
    }
};

Noncompliant Code Example

In this noncompliant code example, a global deallocation is declared noexcept(false) and throws an exception if some conditions are not properly met. However, throwing from a deallocation function results in undefined behavior.

#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
  }
}

Risk Assessment

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