Page History

...

In these situations, the function should logically be declared noexcept, as because throwing an exception from the function can never have well-defined behavior. The C++ Standard, [except.spec], paragraph 15, states [ISO/IEC 14882-2014]:

...

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.

In other circumstances, terminating a function by throwing an exception has a strong potential to trigger undefined behavior. For instance, 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.

...

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, any function declared noexcept which that terminates by throwing an exception does not conform to ERR55-CPP. Honor exception specifications.

...

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. ThusConsequently, it is declared as noexcept(false), but still can still trigger undefined behavior.

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

...

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

...

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 states in part [ISO/IEC 14882-2014]:

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

ThusConsequently, 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 as 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.

...

struct SomeClass {
  ~SomeClass()
    try { // function-try-block
      try {   // ordinaryOrdinary try-block
        // cleanClean up
      } catch(...) {
        // catchCatch and handle exceptions thrown during cleanup
      }
    } catch(...) {
      // catchCatch and log exceptions thrown from non-compliant
      // destructorsDestructors of member objects or base class subobjects

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

...

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.

...