\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 throwing an exception

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}

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

appertains to the 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}).

\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 exception can be thrown from one of the following contexts:

\grammarterm{throw-expression}{s}~(\ref{expr.throw}),

allocation functions~(\ref{basic.stc.dynamic.allocation}),

\tcode{dynamic_cast}~(\ref{expr.dynamic.cast}),

\tcode{typeid}~(\ref{expr.typeid}),

\grammarterm{new-expression}{s}~(\ref{expr.new}), and standard library

functions~(\ref{structure.specifications}).

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.

Throwing an exception

copy-initializes~(\ref{dcl.init}, \ref{class.copy}) a temporary object,

called the

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

The temporary is an lvalue and is used to initialize the

variable declared 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.

\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 a thrown exception 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 constructor selected for

the copy-initialization 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 the initialization of the

exception object but before the activation of a handler for the exception,

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&) {

if (std::uncaught_exceptions()) {

throw 0; // throw during copy to handler's \grammarterm{exception-declaration} object~(\ref{except.handle})

}

}

};

int main() {

try {

throw C(); // calls \tcode{std::terminate()} if construction of the handler's

// \grammarterm{exception-declaration} object is not elided~(\ref{class.copy})

} catch(C) { }

}

\end{codeblock}

\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}}

\indextext{unwinding!stack}%

As control passes from the point where an exception is thrown

to a handler,

destructors are invoked by a process, specified in this section, called

\defn{stack unwinding}. If a destructor directly invoked by stack unwinding

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

Consequently, destructors should generally catch exceptions and not let them

propagate out of the destructor.

The destructor is invoked for each automatic object of class type constructed

since the try block was entered.

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

of their construction.

For an object of class type

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

the destructor is invoked for each of the object's fully constructed

subobjects,

that is, for each subobject for which the principal

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

and the destructor has not yet begun execution,

except that in the case of destruction, the variant members of a

union-like class are not destroyed.

The subobjects are destroyed in the reverse order of the completion of

their construction. Such destruction is sequenced before entering a

handler of the \grammarterm{function-try-block} of the constructor or destructor,

if any.

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 is invoked.

Such destruction is sequenced before entering a handler of the

\grammarterm{function-try-block} of a delegating constructor for that object, if any.

If the object was allocated by a \grammarterm{new-expression}~(\ref{expr.new}),

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

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

\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{cv}

\tcode{T} or \tcode{const T\&} where \tcode{T} is a pointer type

and

\tcode{E}

is a pointer type that can be

converted to \tcode{T}

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, or

\end{itemize}

the \term{handler} is of type \textit{cv} \tcode{T} or \tcode{const T\&} where \tcode{T} 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 integer literal with value 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 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 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}).

The variable declared by the \grammarterm{exception-declaration}, of type

\cv{} \tcode{T} or \cv{} \tcode{T\&}, is initialized from the exception object,

of type \tcode{E}, as follows:

\begin{itemize}

if \tcode{T} is a base class of \tcode{E}, the variable is

copy-initialized~(\ref{dcl.init}) from the corresponding base class subobject

of the exception object;

\item otherwise, the variable is copy-initialized~(\ref{dcl.init})

from the exception object.

\end{itemize}

The lifetime of the variable ends

when the handler exits, after the

destruction of any automatic objects initialized

within the handler.

When the handler declares an object,

any changes to that object will not affect the exception object.

When the handler declares a reference to an object,

any changes to the referenced object are changes to the

exception object 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|(}

\indextext{exception specification!non-throwing}%

The \defn{exception specification} of a function

is a (possibly empty) set of types,

indicating that the function might exit

via an exception

that matches a handler of one of the types in the set;

the (conceptual) set of all types is used

to denote that the function might exit

via an exception

of arbitrary type.

If the set is empty,

the function is said to have

a \defn{non-throwing exception specification}.

The exception specification

is either defined explicitly

by using an \grammarterm{exception-specification}

as a suffix of a function declaration's declarator~(\ref{dcl.fct})

or implicitly.

\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 \tcode{(} token that follows \tcode{noexcept} is part of the

\grammarterm{noexcept-specification} and does not commence an

initializer~(\ref{dcl.init}).

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 a \grammarterm{dynamic-exception-specification}

shall not denote an incomplete type or an rvalue reference type.

A type denoted

in a \grammarterm{dynamic-exception-specification}

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

``pointer to \cv\ \tcode{void}''.

A type

\cv\ \tcode{T},

``array of \tcode{T}'', or

denoted in a \grammarterm{dynamic-exception-specification}

is adjusted to type \tcode{T},

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

A \grammarterm{dynamic-exception-specification}

denotes an exception specification

that is the set of adjusted types specified thereby.

The \grammarterm{exception-specification}

\tcode{noexcept} or \tcode{noexcept(}\grammarterm{constant-expression}{}\tcode{)},

where the \grammarterm{constant-expression} yields \tcode{true},

denotes an exception specification

that is the empty set.

The \grammarterm{exception-specification}

\tcode{noexcept(}\grammarterm{constant-expression}{}\tcode{)},

where the \grammarterm{constant-expression} yields \tcode{false},

or the absence of an \grammarterm{exception-specification}

in a function declarator other than that

for a destructor~(\ref{class.dtor})

or a deallocation function~(\ref{basic.stc.dynamic.deallocation})

denotes an exception specification

that is the set of all types.

\indextext{exception specification!compatible}%

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

\defnx{compatible}{compatible|see{exception specification, compatible}} if

the sets of types they denote are the same.

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

If a declaration of a function has an implicit

exception specification,

other declarations of the function shall not specify an

\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

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

exception specification

of the base class virtual function,

unless the overriding function is defined as deleted.

\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{allowing an exception|see{exception specification, allowing an exception}}%

A function is said to

\defnx{allow an exception}{exception specification!allowing an exception}

of type

\tcode{E}

if

its 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{allowing all exceptions|see{exception specification, allowing all exceptions}}%

A function is said to \defnx{allow all exceptions}{exception specification!allowing all exceptions}

if its exception specification

is the set of all types.

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

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

Whenever an exception of type \tcode{E} is thrown

and the search for a handler~(\ref{except.handle})

encounters the outermost block of a function with an

exception specification that does not allow \tcode{E}, then,

\begin{itemize}

\item if the function definition has 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

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}

might throw exception

\tcode{Y}

that

\tcode{g}

does not allow.

An

exception specification

is not considered part of a function's type;

see~\ref{dcl.fct}.

A \defn{potential exception} of a given context is either a type that might be

thrown as an exception or a pseudo-type, denoted by ``any'', that

represents the situation where an exception of an arbitrary type might

be thrown. A subexpression \tcode{e1} of an expression \tcode{e} is an

\defn{immediate subexpression} if there is no subexpression \tcode{e2} of \tcode{e}

such that \tcode{e1} is a subexpression of \tcode{e2}.

The \defn{set of potential exceptions of a function, function pointer, or

member function pointer} \tcode{f} is defined as follows:

\begin{itemize}

If the exception specification of \tcode{f} is the set of all types,

the set consists of the pseudo-type ``any''.

Otherwise, the set consists of

every type in the exception specification of \tcode{f}.

\end{itemize}

The \defn{set of potential exceptions of an expression} \tcode{e} is empty

if \tcode{e} is a core constant expression (\ref{expr.const}).

Otherwise, it is the union of the sets of potential exceptions of

the immediate subexpressions of \tcode{e},