\rSec0[except]{Exception handling}%

\indextext{exception handling|(}

\indextext{exception object|see{exception handling, exception object}}%

\indextext{object, exception|see{exception handling, exception object}}

Exception handling provides a way of transferring control and information

from a point in the execution of a thread to an exception handler

associated with a point previously passed by the execution.

A handler will be invoked only by a

\grammarterm{throw-expression}

invoked in code executed in the handler's try block

or in functions called from the handler's try block .

\indextext{\idxcode{try}}%

\begin{bnf}

\nontermdef{try-block}\br

\terminal{try} compound-statement handler-seq

\end{bnf}

\indextext{\idxcode{try}}%

\begin{bnf}

\nontermdef{function-try-block}\br

\terminal{try} ctor-initializer\opt compound-statement handler-seq

\end{bnf}

\begin{bnf}

\nontermdef{handler-seq}\br

handler handler-seq\opt

\end{bnf}

\indextext{\idxcode{catch}}%

\begin{bnf}

\nontermdef{handler}\br

\terminal{catch (} exception-declaration \terminal{)} compound-statement

\end{bnf}

\begin{bnf}

\nontermdef{exception-declaration}\br

attribute-specifier-seq\opt type-specifier-seq declarator\br

attribute-specifier-seq\opt type-specifier-seq abstract-declarator\opt\br

\terminal{...}

\end{bnf}

\indextext{\idxcode{throw}}%

\begin{bnf}

\nontermdef{throw-expression}\br

\terminal{throw} assignment-expression\opt

\end{bnf}

The optional \grammarterm{attribute-specifier-seq} in an \grammarterm{exception-declaration}

appertains to the formal parameter of the catch clause~(\ref{except.handle}).

\indextext{exception handling!try block}%

\indextext{exception handling!handler}%

\indextext{try block|see{exception handling, try block}}%

\indextext{handler|see{exception handling, handler}}%

A \grammarterm{try-block} is a \grammarterm{statement} (Clause~\ref{stmt.stmt}).

A \grammarterm{throw-expression} is of type \tcode{void}. Code that executes a

\grammarterm{throw-expression} is said to ``throw an exception;'' code that

subsequently gets control is called a ``handler.'' \enternote Within this Clause

``try block'' is taken to mean both \grammarterm{try-block} and

\grammarterm{function-try-block}. \exitnote

\indextext{exception handling!\idxcode{goto}}%

\indextext{exception handling!\idxcode{switch}}%

\indextext{\idxcode{goto}!and try block}%

\indextext{\idxcode{switch}!and try block}%

\indextext{\idxcode{goto}!and handler}%

\indextext{\idxcode{switch}!and handler}%

A \tcode{goto} or \tcode{switch} statement shall not be used to transfer control

into a try block or into a handler.

\begin{codeblock}

void f() {

goto l1; // Ill-formed

goto l2; // Ill-formed

try {

goto l1; // OK

goto l2; // Ill-formed

l1: ;

} catch (...) {

l2: ;

goto l1; // Ill-formed

goto l2; // OK

}

}

\end{codeblock}

\indextext{\idxcode{goto}!and try block}%

\indextext{\idxcode{switch}!and try block}%

\indextext{\idxcode{return}!and try block}%

\indextext{\idxcode{continue}!and try block}%

\indextext{\idxcode{goto}!and handler}%

\indextext{\idxcode{switch}!and handler}%

\indextext{\idxcode{return}!and handler}%

\indextext{\idxcode{continue}!and handler}%

A

\tcode{goto},

\tcode{break},

\tcode{return},

or

\tcode{continue}

statement can be used to transfer control out of

a try block or handler.

When this happens, each variable declared in the try block

will be destroyed in the context that

directly contains its declaration.

\begin{codeblock}

lab: try {

T1 t1;

try {

T2 t2;

if (@\textit{condition}@)

goto lab;

} catch(...) { /* @\textit{handler 2}@ */ }

} catch(...) { /* @\textit{handler 1}@ */ }

\end{codeblock}

Here, executing

\tcode{goto lab;}

will destroy first

\tcode{t2},

then

\tcode{t1},

assuming the

\grammarterm{condition}

does not declare a variable.

Any exception raised while destroying

\tcode{t2}

will result in executing

\textit{handler 2};

any exception raised while destroying

\tcode{t1}

will result in executing

\textit{handler 1}.

\indextext{function try block|see{exception handling, function try block}}%

\indextext{exception handling!function try block}%

A

\grammarterm{function-try-block}

associates a

\grammarterm{handler-seq}

with the

\grammarterm{ctor-initializer},

if present, and the

\grammarterm{compound-statement}.

An exception

thrown during the execution of the

\grammarterm{compound-statement}

or, for constructors and destructors, during the initialization or

destruction, respectively, of the class's subobjects,

transfers control to a handler in a

\grammarterm{function-try-block}

in the same way as an exception thrown during the execution of a

\grammarterm{try-block}

transfers control to other handlers.

\begin{codeblock}

int f(int);

class C {

int i;

double d;

public:

C(int, double);

};

C::C(int ii, double id)

try : i(f(ii)), d(id) {

// constructor statements

}

catch (...) {

// handles exceptions thrown from the ctor-initializer

// and from the constructor statements

}

\end{codeblock}

\rSec1[except.throw]{Throwing an exception}%

\indextext{exception handling!throwing}%

\indextext{throwing|see{exception handling, throwing}}

Throwing an exception transfers control to a handler.

An object is passed and the type of that object determines which handlers

can catch it.

\begin{codeblock}

throw "Help!";

\end{codeblock}

can be caught by a

\term{handler}

of

\tcode{const}

\tcode{char*}

type:

\begin{codeblock}

try {

// ...

}

catch(const char* p) {

// handle character string exceptions here

}

\end{codeblock}

and

\begin{codeblock}

class Overflow {

public:

Overflow(char,double,double);

};

void f(double x) {

throw Overflow('+',x,3.45e107);

}

\end{codeblock}

can be caught by a handler for exceptions of type

\tcode{Overflow}

\begin{codeblock}

try {

f(1.2);

} catch(Overflow& oo) {

// handle exceptions of type \tcode{Overflow} here

}

\end{codeblock}

\indextext{exception handling!throwing}%

\indextext{exception handling!handler}%

\indextext{exception handling!nearest handler}%

When an exception is thrown, control is transferred to the nearest handler with

a matching type~(\ref{except.handle}); ``nearest'' means the handler

for which the

\grammarterm{compound-statement} or

\grammarterm{ctor-initializer}

following the

\tcode{try}

keyword was most recently entered by the thread of control and not yet exited.

A

\grammarterm{throw-expression}

initializes a temporary object,

called the

\indextext{exception handling!exception object}\term{exception object},

the type of which

is determined by removing any top-level

\grammarterm{cv-qualifier}{s}

from the static type of the operand of

\tcode{throw}

and adjusting the type from ``array of

or ``function returning

to ``pointer to

or ``pointer to function

\tcode{T}'',

respectively.

The temporary is an lvalue and is used to initialize the

variable named in the matching

\term{handler}~(\ref{except.handle}).

If the type of the exception object would

be an incomplete type or a pointer to an incomplete

type other than (possibly cv-qualified)

\tcode{void} the program is ill-formed.

Except for these restrictions and the restrictions on type matching mentioned

in~\ref{except.handle}, the operand of

\tcode{throw}

is treated exactly as a function argument in a call~(\ref{expr.call}) or the operand

of a return statement.

\indextext{exception handling!memory}%

\indextext{exception handling!rethrowing}%

\indextext{exception handling!exception object}%

The memory for the exception object is

allocated in an unspecified way, except as noted in~\ref{basic.stc.dynamic.allocation}.

If a handler exits by rethrowing, control is passed to another handler for

the same exception.

The exception object is destroyed after either

the last remaining active handler for the exception exits by

any means other than

rethrowing, or the last object of type \tcode{std::exception_ptr}~(\ref{propagation})

that refers to the exception object is destroyed, whichever is later. In the former

case, the destruction occurs when the handler exits, immediately after the destruction

of the object declared in the \grammarterm{exception-declaration} in the handler, if any.

In the latter case, the destruction occurs before the destructor of \tcode{std::exception_ptr}

returns.

The implementation may then

deallocate the memory for the exception object; any such deallocation

is done in an unspecified way.

\enternote an exception thrown by a \grammarterm{throw-expression} does not

propagate to other threads unless caught, stored, and rethrown using

appropriate library functions; see~\ref{propagation} and~\ref{futures}. \exitnote

\indextext{exception handling!exception object!constructor}%

\indextext{exception handling!exception object!destructor}%

When the thrown object is a class object, the copy/move constructor and the

destructor shall be accessible, even if the copy/move operation is

elided~(\ref{class.copy}).

\indextext{exception handling!rethrow}%

\indextext{rethrow|see{exception handling, rethrow}}%

\indextext{reraise|see{exception handling, rethrow}}%

An exception is considered caught when a handler for that exception

becomes active~(\ref{except.handle}).

An exception can have active handlers and still be considered uncaught if

it is rethrown.

\indextext{exception handling!terminate called@\tcode{terminate()} called}%

\indextext{\idxcode{terminate()}!called}%

If the exception handling mechanism, after completing evaluation of the expression

to be thrown but before the exception is caught, calls a function that exits via an

exception, \tcode{std::terminate} is called~(\ref{except.terminate}). \enterexample

\begin{codeblock}

struct C {

C() { }

C(const C&) { throw 0; }

};

int main() {

try {

throw C(); // calls \tcode{std::terminate()}

} catch(C) { }

}

\end{codeblock}

\indextext{exception handling!rethrow}%

A

\grammarterm{throw-expression}

with no operand rethrows the currently handled exception~(\ref{except.handle}).

The exception is reactivated with the existing temporary;

no new temporary exception object is created.

The exception

is no longer considered to be caught; therefore, the value

of

\tcode{std::uncaught_exception()}

will again be

\tcode{true}.

code that must be executed because of an exception yet cannot

completely handle the exception can be written like this:

\begin{codeblock}

try {

// ...

} catch (...) { // catch all exceptions

// respond (partially) to exception

throw; // pass the exception to some

// other handler

}

\end{codeblock}

\indextext{exception handling!rethrow}%

\indextext{exception handling!terminate called@\tcode{terminate()} called}%

\indextext{\idxcode{terminate()}!called}%

If no exception is presently being handled,

executing a

\grammarterm{throw-expression}

with no operand calls

\tcode{std\colcol{}terminate()}~(\ref{except.terminate}).

\rSec1[except.ctor]{Constructors and destructors}%

\indextext{exception handling!constructors and destructors}%

\indextext{stack unwinding!see exception handling, constructors and destructors}%

\indextext{constructor!exception~handling|see{exception handling, constructors and destructors}}%

\indextext{destructor!exception~handling|see{exception handling, constructors and destructors}}

As control passes from a

\grammarterm{throw-expression}

to a handler,

destructors are invoked for all automatic objects constructed since the

try block was entered.

The automatic objects are destroyed in the reverse order of the completion

of their construction.

An object

of any storage duration whose initialization or destruction is terminated by an exception

will have

destructors executed for all of its fully constructed

subobjects (excluding the variant members of a union-like class),

that is, for subobjects for which the principal

constructor~(\ref{class.base.init}) has completed execution

and the destructor has not yet begun execution.

Similarly, if the non-delegating constructor for an object has

completed execution and a delegating constructor for that object exits with

an exception, the object's destructor will be invoked.

If the object was allocated in a

\grammarterm{new-expression},

the matching deallocation function~(\ref{basic.stc.dynamic.deallocation}, \ref{expr.new}, \ref{class.free}),

if any, is called to free the storage occupied by the

object.

\indextext{unwinding!stack}%

The process of calling destructors for automatic objects constructed on the

path from a try block to a

\grammarterm{throw-expression}

is called

If a destructor called during stack unwinding exits with an exception,

\tcode{std\-::\-ter\-min\-ate}

is called~(\ref{except.terminate}).

So destructors should generally catch

exceptions and not let them propagate out of the destructor.

\rSec1[except.handle]{Handling an exception}

\indextext{exception handling!handler|(}%

The

\grammarterm{exception-declaration}

in a

\term{handler}

describes the type(s) of exceptions that can cause

that

\term{handler}

to be entered.

\indextext{exception handling!handler!incomplete type in}%

\indextext{exception handling!handler!rvalue reference in}%

\indextext{exception handling!handler!array in}%

\indextext{exception handling!handler!pointer to function in}%

The

\grammarterm{exception-declaration}

shall not denote an incomplete type, an abstract class type, or an rvalue reference type.

The

\grammarterm{exception-declaration}

shall not denote a pointer or reference to an

incomplete type, other than

\tcode{void*},

\tcode{const}

\tcode{void*},

\tcode{volatile}

\tcode{void*},

or

\tcode{const}

\tcode{volatile}

\tcode{void*}.

A handler of type ``array of

or ``function returning

is adjusted to be of type ``pointer to

or ``pointer to function

\tcode{T}'',

respectively.

\indextext{exception handling!handler!match|(}%

A

\term{handler}

is a match for

an exception object

of type

\tcode{E}

if

\begin{itemize}

The

\term{handler}

is of type

\textit{cv}

\tcode{T}

or

\textit{cv}

\tcode{T\&}

and

\tcode{E}

and

\tcode{T}

are the same type (ignoring the top-level

\grammarterm{cv-qualifiers}),

or

the

\term{handler}

is of type

\textit{cv}

\tcode{T}

or

\textit{cv}

\tcode{T\&}

and

\tcode{T}

is an unambiguous public base class of

\tcode{E},

or

the

\term{handler}

is of type

\textit{cv1}

\tcode{T*}

\textit{cv2}

and

\tcode{E}

is a pointer type that can be

converted to the type of the

\term{handler}

by either or both of

\begin{itemize}

a standard pointer conversion~(\ref{conv.ptr}) not involving conversions

to pointers to private or protected or ambiguous classes

a qualification conversion

\end{itemize}

the \term{handler} is a pointer or pointer to member type and \tcode{E} is \tcode{std::nullptr_t}.

\end{itemize}

A

\grammarterm{throw-expression}

whose operand is an integral constant expression of integer type

that evaluates to zero does not match a handler of pointer or pointer to member type.

\begin{codeblock}

class Matherr { /* ... */ virtual void vf(); };

class Overflow: public Matherr { /* ... */ };

class Underflow: public Matherr { /* ... */ };

class Zerodivide: public Matherr { /* ... */ };

void f() {

try {

g();

} catch (Overflow oo) {

// ...

} catch (Matherr mm) {

// ...

}

}

\end{codeblock}

Here, the

\tcode{Overflow}

handler will catch exceptions of type

\tcode{Overflow}

and the

\tcode{Matherr}

handler will catch exceptions of type

\tcode{Matherr}

and of all types publicly derived from

\tcode{Matherr}

including exceptions of type

\tcode{Underflow}

and

\tcode{Zerodivide}.

The handlers for a try block are tried in order of appearance.

That makes it possible to write handlers that can never be

executed, for example by placing a handler for a derived class after

a handler for a corresponding base class.

A

\tcode{...}

in a handler's

\grammarterm{exception-declaration}

functions similarly to

\tcode{...}

in a function parameter declaration;

it specifies a match for any exception.

If present, a

\tcode{...}

handler shall be the last handler for its try block.

If no match is found among the handlers for a try block,

the search for a matching

handler continues in a dynamically surrounding try block

of the same thread.

A handler is considered active when initialization is complete for

the formal parameter (if any) of the catch clause.

The stack will have been unwound at that point.

Also, an implicit handler is considered active when

\tcode{std::terminate()}

or

\tcode{std::unexpected()}

is entered due to a throw. A handler is no longer considered active when the

catch clause exits or when

\tcode{std::unexpected()}

exits after being entered due to a throw.

The exception with the most recently activated handler that is

still active is called the

\term{currently handled exception}.

If no matching handler is found,

the function

\tcode{std::terminate()}

is called;

whether or not the stack is unwound before this call to

\tcode{std::terminate()}

is \impldef{stack unwinding before call to

\tcode{std::terminate()}}~(\ref{except.terminate}).

Referring to any non-static member or base class of an object

in the handler for a

\grammarterm{function-try-block}

of a constructor or destructor for that object results in undefined behavior.

The fully constructed base classes and members of an object shall

be destroyed before entering the handler of a

\grammarterm{function-try-block}

of a constructor for that object.

Similarly, if a delegating constructor for an object exits

with an exception after the non-delegating constructor for that object

has completed execution, the object's destructor shall be executed before

entering the handler of a \nonterminal{function-try-block} of a

constructor for that object. The base classes and non-variant members of an object shall be destroyed before entering the handler of a \nonterminal{function-try-block} of a destructor for that object~(\ref{class.dtor}).

The scope and lifetime of the parameters of a function or constructor

extend into the handlers of a

\grammarterm{function-try-block}.

Exceptions thrown in destructors of objects with static storage duration or in

constructors of namespace-scope objects with static storage duration are not caught by a

\grammarterm{function-try-block}

on

\tcode{main()}. Exceptions thrown in destructors of objects with thread storage duration or in constructors of namespace-scope objects with thread storage duration are not caught by a

\grammarterm{function-try-block}

on the initial function of the thread.

If a return statement appears in a handler of the

\grammarterm{function-try-block}

of a

constructor, the program is ill-formed.

The currently handled exception

is rethrown if control reaches the end of a handler of the

\grammarterm{function-try-block}

of a constructor or destructor.

Otherwise, a

function returns when control reaches the end of a handler for

the

\grammarterm{function-try-block}~(\ref{stmt.return}).

Flowing off the end of a

\grammarterm{function-try-block}

is equivalent to a

\tcode{return}

with no value;

this results in undefined behavior in a value-returning function~(\ref{stmt.return}).

If the \grammarterm{exception-declaration} specifies a name, it declares a

variable which is copy-initialized~(\ref{dcl.init}) from the exception object.

If the \grammarterm{exception-declaration} denotes an object type but

does not specify a name, a

temporary~(\ref{class.temporary}) is copy-initialized~(\ref{dcl.init}) from the

exception object.

The lifetime of the variable or temporary ends

when the handler exits, after the

destruction of any automatic objects initialized

within the handler.

When the handler declares a non-constant object,

any changes to that object will not affect the temporary object

that was initialized by execution of the

\grammarterm{throw-expression}.

When the handler declares a reference to a non-constant object,

any changes to the referenced object are changes to the

temporary object initialized when the

\grammarterm{throw-expression}

was executed and will have effect should that object be rethrown.%

\indextext{exception handling!handler!match|)}%

\indextext{exception handling!handler|)}

\rSec1[except.spec]{Exception specifications}%

\indextext{exception specification|(}

A function declaration lists exceptions

that its function might directly or indirectly throw

by using an

\grammarterm{exception-specification}

as a suffix of its declarator.

\begin{bnf}

\nontermdef{exception-specification}\br

dynamic-exception-specification\br

noexcept-specification

\end{bnf}

\begin{bnf}

\nontermdef{dynamic-exception-specification}\br

\terminal{throw (} type-id-list\opt \terminal{)}

\end{bnf}

\begin{bnf}

\nontermdef{type-id-list}\br

type-id \terminal{...}\opt\br

type-id-list \terminal{,} type-id \terminal{...}\opt

\end{bnf}

\begin{bnf}

\nontermdef{noexcept-specification}\br

\terminal{noexcept} \terminal{(} constant-expression \terminal{)}\br

\terminal{noexcept}

\end{bnf}

\indextext{exception specification!noexcept!constant expression and}%

In a \grammarterm{noexcept-specification}, the \grammarterm{constant-expression},

if supplied, shall be a constant expression~(\ref{expr.const}) that is contextually

converted to \tcode{bool} (Clause~\ref{conv}). A \grammarterm{noexcept-specification}

\tcode{noexcept} is equivalent to \tcode{noexcept(\brk{}true)}.

An

\grammarterm{exception-specification}

shall appear only on a function declarator for a function type,

pointer to function type, reference to function type, or pointer to

member function type that is the top-level type of a declaration or

definition, or on such a type appearing as a parameter or return type

in a function declarator.

An

\grammarterm{exception-specification}

shall not appear in a typedef declaration or \grammarterm{alias-declaration}.

\begin{codeblock}

void f() throw(int); // OK

void (*fp)() throw (int); // OK

void g(void pfa() throw(int)); // OK

typedef int (*pf)() throw(int); // ill-formed

\end{codeblock}

\indextext{exception specification!incomplete type and}%

A type denoted in an

\grammarterm{exception-specification}

shall not denote an incomplete type.

A type denoted in an

\grammarterm{exception-specification}

shall not denote a pointer or reference to an incomplete type, other than

\tcode{void*},

\tcode{const}

\tcode{void*},

\tcode{volatile}

\tcode{void*},

or

\tcode{const}

\tcode{volatile}

\tcode{void*}.

A type \cv\ \tcode{T}, ``array of \tcode{T}'', or ``function returning \tcode{T}''

denoted in an \grammarterm{exception-specification} is adjusted to type \tcode{T},

``pointer to \tcode{T}'', or ``pointer to function returning \tcode{T}'', respectively.

\indextext{exception specification!compatible}%

Two \grammarterm{exception-specification}{s} are

\indextext{compatible|see{exception specification, compatible}}\term{compatible} if:

\begin{itemize}

\item both are non-throwing (see below), regardless of their form,

\item both have the form \tcode{noexcept(}\grammarterm{constant-expression}{}\tcode{)}

and the \grammarterm{constant-expression}{s} are equivalent, or

\item both are \grammarterm{dynamic-exception-specification}{s} that have the same

set of adjusted types.

\end{itemize}

If any declaration of a function has an

\grammarterm{exception-specification}

that is not a \grammarterm{noexcept-specification} allowing all exceptions,

all declarations, including the definition and any explicit specialization,

of that function shall have a compatible

\grammarterm{exception-specification}.

If any declaration of a pointer to function, reference to function,

or pointer to member function has an

\grammarterm{exception-specification},

all occurrences of that declaration shall have a compatible

\grammarterm{exception-specification}

In an explicit instantiation an

\grammarterm{exception-specification}

may be specified, but is not required.

If an

\grammarterm{exception-specification}

is specified in an explicit instantiation directive, it shall

be compatible with the \grammarterm{exception-specification}{s} of

other declarations of that function.

A diagnostic is required only if the

\grammarterm{exception-specification}{s} are not compatible

within a single translation unit.

\indextext{exception specification!virtual function and}%

If a virtual function has an

\grammarterm{exception-specification},

all declarations, including the definition, of any function

that overrides that virtual function in any derived class

shall only allow exceptions that are allowed by the

\grammarterm{exception-specification}

of the base class virtual function.

\begin{codeblock}

struct B {

virtual void f() throw (int, double);

virtual void g();

};

struct D: B {

void f(); // ill-formed

void g() throw (int); // OK

};

\end{codeblock}

The declaration of

\tcode{D::f}

is ill-formed because it allows all exceptions, whereas

\tcode{B::f}

allows only

\tcode{int}

and

\tcode{double}.

A similar restriction applies to assignment to and

initialization of pointers to functions, pointers

to member functions, and references to functions:

the target entity shall allow at least the exceptions

allowed by the source value in the assignment or

initialization.

\begin{codeblock}

class A { /* ... */ };

void (*pf1)(); // no exception specification

void (*pf2)() throw(A);

void f() {

pf1 = pf2; // OK: \tcode{pf1} is less restrictive

pf2 = pf1; // error: \tcode{pf2} is more restrictive

}

\end{codeblock}

In such an assignment or initialization,

\grammarterm{exception-specification}{s}

on return types and parameter types shall be compatible.

In other assignments or initializations,

\grammarterm{exception-specification}{s}

shall be compatible.

An

\grammarterm{exception-specification}

can include the same type more than once

and can include classes that are related by inheritance,

even though doing so is redundant.

\enternote An

\grammarterm{exception-specification}

can also include the class

\tcode{std::bad_exception}~(\ref{bad.exception}).

\indextext{exception handling!allowing an exception}%

\indextext{allowing an exception|see{exception handling, allowing an exception}}%

A function is said to

\term{allow}

an exception of type

\tcode{E}

if

the \grammarterm{constant-expression} in its \grammarterm{noexcept-specification}

evaluates to \tcode{false} or

its

\grammarterm{dynamic-exception-specification}

contains a type

\tcode{T}

for which a handler of type

\tcode{T}

would be a match~(\ref{except.handle}) for an exception of type

\tcode{E}.

\indextext{exception handling!unexpected called@\tcode{unexpected()} called}%

\indextext{\idxcode{unexpected()}!called}%

Whenever an exception is thrown and the search for a handler~(\ref{except.handle})

encounters the outermost block of a function with an

\grammarterm{exception-specification} that does not allow the exception, then,

\begin{itemize}

\item if the \grammarterm{exception-specification} is a

\grammarterm{dynamic-exception-specification}, the function

\tcode{std::unexpected()} is called~(\ref{except.unexpected}),

\indextext{exception handling!terminate called@\tcode{terminate()} called}%

\indextext{\idxcode{terminate()}!called}%

\item otherwise, the function \tcode{std::terminate()} is called~(\ref{except.terminate}).

\end{itemize}

\begin{codeblock}

class X { };

class Y { };

class Z: public X { };

class W { };

void f() throw (X, Y) {

int n = 0;

if (n) throw X(); // OK

if (n) throw Z(); // also OK

throw W(); // will call \tcode{std::unexpected()}

}

\end{codeblock}

\enternote A function can have multiple declarations with different non-throwing

\grammarterm{exception-specification}{s}; for this purpose, the one on the

function definition is used. \exitnote

\indextext{\idxcode{unexpected()}}%

The function

\tcode{unexpected()}

may throw an exception that will satisfy the

\grammarterm{exception-specification}

for which it was invoked, and in this case the search for another handler

will continue at the call of the function with this

\grammarterm{exception-specification}

(see~\ref{except.unexpected}), or it may call

\tcode{std::terminate()}.

An implementation shall not reject an expression merely because when

executed it throws or might

throw an exception that the containing function does not allow.

\begin{codeblock}

extern void f() throw(X, Y);

void g() throw(X) {

f(); // OK

}

\end{codeblock}

the call to

\tcode{f}

is well-formed even though when called,

\tcode{f}