Page History

...

Any noexcept function that terminates by throwing 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 has_error() const;
 
public:
  ~S() noexcept(false) {
    // Normal processing
    if (has_error()) {
      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 has_error() const;
 
public:
  ~S() noexcept(false) {
    // Normal processing
    if (has_error() && !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:

...

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

Compliant Code Example

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 the end of the handler due to the explicit return statement. This handler will catch the exception thrown by Bad::~Bad() when bad_member is destroyed, and it will also catch any exceptions thrown within the the compound statement of the function-try-block.

#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 a destructor function-try-block causes
    // the caught exception to be implicitly rethrown, but an
    // explicit return statement will prevent that from happening.
    return;
  }
};

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

...