[except.terminate]

Some errors in a program cannot be recovered from, such as when an exception is not handled or a std::thread object is destroyed while its thread function is still executing.

In such cases, the function std::terminate ([exception.terminate]) is invoked.

[Note 1:

These situations are:

(1.1)
when the exception handling mechanism, after completing the initialization of the exception object but before activation of a handler for the exception ([except.throw]), calls a function that exits via an exception, or
(1.2)
when the exception handling mechanism cannot find a handler for a thrown exception ([except.handle]), or
(1.3)
when the search for a handler exits the function body of a function with a non-throwing exception specification, including when a contract-violation handler invoked from an evaluation of a function contract assertion ([basic.contract.eval]) associated with the function exits via an exception, or
(1.4)
when the destruction of an object during stack unwinding terminates by throwing an exception, or
(1.5)
when initialization of a non-block variable with static or thread storage duration ([basic.start.dynamic]) exits via an exception, or
(1.6)
when destruction of an object with static or thread storage duration exits via an exception ([basic.start.term]), or
(1.7)
when execution of a function registered with std::atexit or std::at_quick_exit exits via an exception ([support.start.term]), or
(1.8)
when a throw-expression ([expr.throw]) with no operand attempts to rethrow an exception and no exception is being handled ([except.throw]), or
(1.9)
when the function std::nested_exception::rethrow_nested is called for an object that has captured no exception ([except.nested]), or
(1.10)
when execution of the initial function of a thread exits via an exception ([thread.thread.constr]), or
(1.11)
for a parallel algorithm whose ExecutionPolicy specifies such behavior ([execpol.seq], [execpol.par], [execpol.parunseq]), when execution of an element access function ([algorithms.parallel.defns]) of the parallel algorithm exits via an exception ([algorithms.parallel.exceptions]), or
(1.12)
when the destructor or the move assignment operator is invoked on an object of type std::thread that refers to a joinable thread ([thread.thread.destr], [thread.thread.assign]), or
(1.13)
when a call to a wait(), wait_until(), or wait_for() function on a condition variable ([thread.condition.condvar], [thread.condition.condvarany]) fails to meet a postcondition, or
(1.14)
when a callback invocation exits via an exception when requesting stop on a std::stop_source or a std::inplace_stop_source ([stopsource.mem], [stopsource.inplace.mem]), or in the constructor of std::stop_callback or std::inplace_stop_callback ([stopcallback.cons], [stopcallback.inplace.cons]) when a callback invocation exits via an exception, or
(1.15)
when a run_loop object is destroyed that is still in the running state ([exec.run.loop]), or
(1.16)
when unhandled_stopped is called on a with_awaitable_senders<T> object ([exec.with.awaitable.senders]) whose continuation is not a handle to a coroutine whose promise type has an unhandled_stopped member function, or
(1.17)
when an object scope of type std::execution::simple_counting_scope or std::execution::counting_scope is destroyed and scope.state is not equal to joined, unused, or unused-and-closed ([exec.simple.counting.ctor]), or
(1.18)
when std::execution::get_parallel_scheduler is called and std::execution::system_context_replaceability::query_parallel_scheduler_backend() returns a null pointer value ([exec.par.scheduler]), or
(1.19)
when an exception is thrown from a coroutine std::execution::task ([exec.task]) which doesn't support a std::execution::set_error_t(std::exception_ptr) completion.

— end note]

In the situation where no matching handler is found, it is implementation-defined whether or not the stack is unwound before std::terminate is invoked.

In the situation where the search for a handler ([except.handle]) exits the function body of a function with a non-throwing exception specification ([except.spec]), it is implementation-defined whether the stack is unwound, unwound partially, or not unwound at all before the function std::terminate is invoked.

In all other situations, the stack shall not be unwound before the function std::terminate is invoked.

An implementation is not permitted to finish stack unwinding prematurely based on a determination that the unwind process will eventually cause an invocation of the function std::terminate.