Page History

The std::abort(), std::quick_exit(), and std::_Exit() functions are used to terminate the program in an immediate fashion. They do so without calling exit handlers registered with std::atexit() and without executing destructors for objects with automatic, thread, or static storage duration. How a system manages open streams when a program ends is implementation-defined [ISO/IEC 9899:1999]. Open streams with unwritten buffered data may or may not be flushed, open streams may or may not be closed, and temporary files may or may not be removed. Because these functions can leave external resources, such as files and network communications, in an indeterminate state, they should be called explicitly only in direct response to a critical error in the application. (See ERR50-CPP-EX1 for more information.)

The std::terminate() function calls the current terminate_handler function, which defaults to calling std::abort().

The C++ Standard defines several ways in which std::terminate() may be called implicitly by an implementation [ISO/IEC 14882-2014]:

1. When the exception handling mechanism, after completing the initialization of the exception object but before activation of a handler for the exception, calls a function that exits via an exception ([except.throw], paragraph 7)
   
   • See ERR60-CPP. Exception objects must be nothrow copy constructible for more information.
2. When a throw-expression with no operand attempts to rethrow an exception and no exception is being handled ([except.throw], paragraph 9)
3. When

Thrown exceptions that are not explicitly caught subject the program to several implementation-dependent issues. C++2004, section 15.5.1 "The std::terminate() function", says:

...

1. the exception handling mechanism cannot find a handler for a thrown exception ([except.handle], paragraph 9)
   • See ERR51-CPP. Handle all exceptions for more information.
2. When the search for a handler encounters the outermost block of a function with a noexcept-specification that does not allow the exception ([except.spec], paragraph 9)
   • See ERR55-CPP. Honor exception specifications for more information.
3. When the destruction of an object during stack unwinding terminates by throwing an exception ([except.ctor], paragraph 3)
   • See DCL57-CPP. Do not let exceptions escape from destructors or deallocation functions for more information.
4. When initialization of a nonlocal variable with static or thread storage duration exits via an exception ([basic.start.init], paragraph 6)
   
   • See ERR58-CPP. Handle all exceptions thrown before main() begins executing for more information.
5. When destruction of an object with static or thread storage duration exits via an exception ([basic.start.term], paragraph 1)
   • See DCL57-CPP. Do not let exceptions escape from destructors or deallocation functions for more information.
6. When execution of a function registered with std::atexit()or std::at_quick_exit() exits via an exception ([support.start.term], paragraphs 8 and 12)
7. When the implementation’s default unexpected exception handler is called ([except.unexpected], paragraph 2)
   Note that std::unexpected() is currently deprecated.
8. When std::unexpected() throws an exception that is not allowed by the previously violated dynamic-exception-specification, and std::bad_exception() is not included in that dynamic-exception-specification ([except.unexpected], paragraph 3)
   
9. When the function std::nested_exception::rethrow_nested() is called for an object that has captured no exception ([except.nested], paragraph 4)
   
10. When execution of the initial function of a thread exits via an exception ([thread.thread.constr], paragraph 5)
    • See ERR51-CPP. Handle all exceptions for more information.
11. When the destructor is invoked on an object of type std::thread that refers to a joinable thread ([thread.thread.destr], paragraph 1)
12. When the copy assignment operator is invoked on an object of type std::thread that refers to a joinable thread ([thread.thread.assign], paragraph 1)
    
13. When calling condition_variable::wait(), condition_variable::wait_until(), or condition_variable::wait_for() results in a failure to meet the postcondition: lock.owns_lock() == true or lock.mutex() is not locked by the calling thread ([thread.condition.condvar], paragraphs 11, 16, 21, 28, 33, and 40)
14. When calling condition_variable_any::wait(), condition_variable_any::wait_until(), or condition_variable_any::wait_for() results in a failure to meet the postcondition: lock is not locked by the calling thread ([thread.condition.condvarany], paragraphs 11, 16, and 22)

In many circumstances, the call stack will not be unwound in response to an implicit call to std::terminate(), and in a few cases, it is implementation-defined whether or not stack unwinding will occur. The C++ Standard, [except.terminate], paragraph 2 [ISO/IEC 14882-2014], in part, states the following:

In the exception (15.3).In such cases, std::terminate() is called (18.7.3). In the situation where no matching handler is found, it  it is implementation-defined whether or not the stack is unwound before std::terminate() is called. In the situation where the search for a handler encounters the outermost block of a function with a noexcept-specification that does not allow the exception, it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before std::terminate() is called. In all other situationsother situations, the stack shall not be unwound before std::terminate() is  is called. An implementation is not permitted to finish stack unwinding prematurely based on a determination that the unwind process will eventually cause a call to std::terminate().

Consequently you should take steps to prevent std::terminate() from being invoked for two reasons. First because it involves implementation-defined behavior. Second, if the stack is not unwound on your platform, than RAII is violated. That is, destructors are not called, allocated memory is not freed, opened files are not flushed and closed, etc.

Non-Compliant Code Example (main())

Do not explicitly or implicitly call std::quick_exit(),  std::abort(), or std::_Exit(). When the default terminate_handler is installed or the current terminate_handler responds by calling std::abort() or std::_Exit(), do not explicitly or implicitly call std::terminate(). Abnormal process termination is the typical vector for denial-of-service attacks.

It is acceptable to call a termination function that safely executes destructors and properly cleans up resources, such as std::exit().

Noncompliant Code Example

In this noncompliant code example, the call to f(), which was registered as an exit handler with std::at_exit(), may result in a call to std::terminate() because throwing_func() may throw an exceptionIn this example, main() does several useful work but does not catch any exceptions. Consequently, any exceptions thrown will call std::terminate(), and might not destroy any objects owned by the program.

#include <cstdlib>
 
intvoid mainthrowing_func(int argc, char** argv) {
  Object object;) noexcept(false);
 
void f() { // mightNot notinvoked getby destroyedthe ifprogram exceptionexcept thrown
as an // do useful workexit handler.
  return 0throwing_func();
}

Compliant Solution (main())

In this code example, all exceptions are caught, allowing normal termination, even in the face of unexpected errors.

 
int main(int argc, char** argv) {
  Object object;
  bool error = false;

  tryif (0 != std::atexit(f)) {
    // do useful work
  } catch (...) {
    error = true;Handle error
  }

  return error ? -1 : 0; // object gets destroyed here...
}

Compliant Solution

...

In this compliant solution, f() handles all exceptions thrown by throwing_func() and does not rethrowAn alternative is to wrap all of main()'s functionality inside a try-catch block.

Code Block
bgColor #ccccff lang
int main(int argc, char** argv) { try { Object object; // do useful work return 0; // object gets destroyed here } catch (...) { throw; } }

Non-Compliant Code Example (throw() Declaration)

A function that declares exception specifications must include every exception that might be thrown during its invocation. If an exception is thrown that is not included in its specification, control automatically reverts to std::unexpected(), which does not return.

In the following code example, the function f() claims to throw exception1 but actually throws exception2. Consequently control flow is diverted to std::unexpected, and the toplevel catch clause may not be invoked. (It is not invoked on Linux with G++ 4.3).

#include <cstdlib>

void throwing_func() noexcept(false);

void f() { // Not invoked by the program except as an exit handler.
  try {
    throwing_func();
  } catch (...) {
    // Handle error
  }

using namespace std;
class exception1 : public exception {};
class exception2 : public exception {};

void f(void) throw( exception1) {
  // ...
  throw (exception2());
}

int main() {
  try {
    f();
    return 0;
  } catch (...if (0 != std::atexit(f)) {
    cerr// << "F called" << endl;Handle error
  }
  return -1;// ...
}

Compliant Solution (throw() Declaration)

Exceptions

ERR50-CPP-EX1: It is acceptable, after indicating the nature of the problem to the operator, to explicitly call std::abort(), std::_Exit(), or std::terminate() in response to a critical program error for which no recovery is possible, as in this example.The following code example declares the same exception it actually throws

#include <exception>

void report(const char *msg) noexcept;
[[noreturn]] void fast_fail(const char *msg) {
  // Report error message to operator
  report(msg);
 
using namespace std;
class exception1 : public exception {};
class exception2 : public exception {};

void f(void) throw( exception1) {
  // ...Terminate
  throw (exception1());
}

int mainstd::terminate();
}
 
void critical_function_that_fails() noexcept(false);
 
void f() {
  try {
    fcritical_function_that_fails();
    return 0;
  } catch (...) {
    cerr << "F called" << endlfast_fail("Critical function failure");
  }
  return -1;
}
}

The assert() macro is permissible under this exception because failed assertions will notify the operator on the standard error stream in an implementation-defined manner before calling std::abort().

Risk Assessment

Failing to handle exceptions Allowing the application to abnormally terminate can lead to resources not being freed, closed, etcand so on. It is frequently a vector for denial-of-service attacks.

Other Languages

This rule appears in the Java Secure Coding Standard as EXC03-J. Try to recover gracefully from system errors.

References

\[[ISO/IEC 14882-2003|AA. C++ References#ISO/IEC 14882-2003]\]
\[[MISRA 08|AA. C++ References#MISRA 08]\] Rule 15-3-2

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

Image Added Image Added Image Added ERR09-CPP. Throw anonymous temporaries and catch by reference      12. Exceptions and Error Handling (ERR)      ERR31-CPP. Don't redefine errno