Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

1297 lines (1166 sloc) 39.366 kB
\rSec0[except]{Exception handling}%
\indextext{exception handling|(}
%gram: \rSec1[gram.except]{Exception handling}
%gram:
\indextext{exception object|see{exception handling, exception object}}%
\indextext{object, exception|see{exception handling, exception object}}
\pnum
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}).
\pnum
\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
\pnum
\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.
\enterexample
\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}
\exitexample
\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.
\enterexample
\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}.
\exitexample
\pnum
\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.
\enterexample
\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}
\exitexample
\rSec1[except.throw]{Throwing an exception}%
\indextext{exception handling!throwing}%
\indextext{throwing|see{exception handling, throwing}}
\pnum
Throwing an exception transfers control to a handler.
An object is passed and the type of that object determines which handlers
can catch it.
\enterexample
\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}
\exitexample
\pnum
\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.
\pnum
A
\grammarterm{throw-expression}
copy-initializes~(\ref{dcl.init}) 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
\tcode{T}''
or ``function returning
\tcode{T}''
to ``pointer to
\tcode{T}''
or ``pointer to function
returning
\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.
\pnum
\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
\pnum
\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}).
\pnum
\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}).
\enternote
An exception can have active handlers and still be considered uncaught if
it is rethrown.
\exitnote
\pnum
\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}
\exitexample
\pnum
\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}.
\enterexample
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}
\exitexample
\pnum
\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}}
\pnum
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.
\pnum
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.
\pnum
\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
``\term{stack unwinding}.''
If a destructor called during stack unwinding exits with an exception,
\tcode{std\-::\-ter\-min\-ate}
is called~(\ref{except.terminate}).
\enternote
So destructors should generally catch
exceptions and not let them propagate out of the destructor.
\exitnote
\rSec1[except.handle]{Handling an exception}
\indextext{exception handling!handler|(}%
\pnum
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*}.
\pnum
A handler of type ``array of
\tcode{T}''
or ``function returning
\tcode{T}''
is adjusted to be of type ``pointer to
\tcode{T}''
or ``pointer to function
returning
\tcode{T}'',
respectively.
\pnum
\indextext{exception handling!handler!match|(}%
A
\term{handler}
is a match for
an exception object
of type
\tcode{E}
if
\begin{itemize}
\item%
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
\item%
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
\item%
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}
\item%
a standard pointer conversion~(\ref{conv.ptr}) not involving conversions
to pointers to private or protected or ambiguous classes
\item%
a qualification conversion
\end{itemize}
\item
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}
\enternote
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.
\exitnote
\enterexample
\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}.
\exitexample
\pnum
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.
\pnum
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.
\pnum
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.
\pnum
A handler is considered active when initialization is complete for
the formal parameter (if any) of the catch clause.
\enternote
The stack will have been unwound at that point.
\exitnote
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.
\pnum
The exception with the most recently activated handler that is
still active is called the
\term{currently handled exception}.
\pnum
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}).
\pnum
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.
\pnum
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}).
\pnum
The scope and lifetime of the parameters of a function or constructor
extend into the handlers of a
\grammarterm{function-try-block}.
\pnum
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.
\pnum
If a return statement appears in a handler of the
\grammarterm{function-try-block}
of a
constructor, the program is ill-formed.
\pnum
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}).
\pnum
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.
\pnum
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|(}
\pnum
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)}.
\pnum
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}.
\enterexample
\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}
\exitexample
\indextext{exception specification!incomplete type and}%
A type denoted in an
\grammarterm{exception-specification}
shall not denote an incomplete type other than a class currently being defined.
A type denoted in an
\grammarterm{exception-specification}
shall not denote a pointer or reference to an incomplete type, other than
\term{cv} \tcode{void*} or a pointer or reference to a class currently being defined.
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.
\pnum
\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}
\pnum
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.
\pnum
\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.
\enterexample
\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}.
\exitexample
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.
\enterexample
\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}
\exitexample
\pnum
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.
\pnum
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}).
\exitnote
\pnum
\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}.
\pnum
\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}
\enterexample
\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}
\exitexample
\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
\pnum
\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()}.
\pnum
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.
\enterexample
\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.
\exitexample
\pnum
A function with no
\grammarterm{exception-specification}
or with an \grammarterm{exception-specification} of the form
\tcode{noexcept(}\grammarterm{constant-expression}\tcode{)} where
the \grammarterm{constant-expression} yields \tcode{false}
allows all exceptions.
An \grammarterm{exception-specification} is \defn{non-throwing} if it is of the
form \tcode{throw()}, \tcode{noexcept}, or
\tcode{noexcept(}\grammarterm{constant-expression}\tcode{)} where the
\grammarterm{constant-expression} yields \tcode{true}.
A function with a non-throwing
\grammarterm{exception-specification}
does not allow any exceptions.
\pnum
An
\grammarterm{exception-specification}
is not considered part of a function's type.
\pnum
An inheriting constructor~(\ref{class.inhctor}) and an implicitly declared
special member function (Clause~\ref{special}) have an
\grammarterm{exception-specification}.
If
\tcode{f}
is an inheriting constructor or an implicitly declared default constructor,
copy constructor,
move constructor,
destructor,
copy assignment operator,
or move assignment operator,
its implicit
\grammarterm{exception-specification} specifies
the
\grammarterm{type-id}
\tcode{T}
if and only if
\tcode{T}
is allowed by the \grammarterm{exception-specification} of a function directly
invoked by \tcode{f}'s
implicit
definition;
\tcode{f}
allows all exceptions if any function it directly invokes allows all
exceptions, and
\tcode{f}
has the \grammarterm{exception-specification} \tcode{noexcept(true)} if every function it directly invokes allows no
exceptions.
\enternote An instantiation of an inheriting constructor template has
an implied \grammarterm{exception-specification} as if it were a non-template
inheriting constructor.\exitnote
\enterexample
\begin{codeblock}
struct A {
A();
A(const A&) throw();
A(A&&) throw();
~A() throw(X);
};
struct B {
B() throw();
B(const B&) throw();
B(B&&) throw(Y);
~B() throw(Y);
};
struct D : public A, public B {
// Implicit declaration of \tcode{D::D();}
// Implicit declaration of \tcode{D::D(const D\&) noexcept(true);}
// Implicit declaration of \tcode{D::D(D\&\&) throw(Y);}
// Implicit declaration of \tcode{D::$\sim$D() throw(X, Y);}
};
\end{codeblock}
Furthermore, if
\tcode{A::\~{}A()}
or
\tcode{B::\~{}B()}
were virtual,
\tcode{D::\~{}D()}
would not be as restrictive as that of
\tcode{A::\~{}A},
and the program would be ill-formed since a function that overrides a virtual
function from a base class shall have an \grammarterm{exception-specification}
at least as restrictive as that in the base class.
\exitexample
\pnum
A deallocation function~(\ref{basic.stc.dynamic.deallocation}) with no explicit
\grammarterm{exception-specification} is treated as if it were specified with
\tcode{noexcept(true)}.
\pnum
In a \grammarterm{dynamic-exception-specification}, a
\grammarterm{type-id} followed by an ellipsis is a
pack expansion~(\ref{temp.variadic}).
\pnum
\enternote The use of \grammarterm{dynamic-exception-specification}{s} is deprecated
(see Annex~\ref{depr}). \exitnote%
\indextext{exception specification|)}
\rSec1[except.special]{Special functions}
\pnum
The functions \tcode{std::terminate()}~(\ref{except.terminate}) and
\tcode{std::unexpected()}~(\ref{except.unexpected}) are used by the exception
handling mechanism for coping with errors related to the exception handling
mechanism itself. The function
\tcode{std::current_exception()}~(\ref{propagation}) and the class
\tcode{std::nested_exception}~(\ref{except.nested}) can be used by a program to
capture the currently handled exception.
\rSec2[except.terminate]{The \tcode{std::terminate()} function}
\pnum
\indextext{\idxcode{terminate()}}%
In some situations exception handling must be abandoned
for less subtle error handling techniques. \enternote These situations are:
\indextext{\idxcode{terminate()}!called}%
\begin{itemize}
\item%
when the exception handling mechanism, after completing
the initialization of the exception object
but before
activation of a handler for the exception~(\ref{except.throw}),
calls a function that exits
via an exception, or
\item%
when the exception handling mechanism cannot find a handler for a thrown exception~(\ref{except.handle}), or
\item when the search for a handler~(\ref{except.handle}) encounters the
outermost block of a function with a \grammarterm{noexcept-specification}
that does not allow the exception~(\ref{except.spec}), or
\item%
when the destruction of an object during stack unwinding~(\ref{except.ctor})
terminates by throwing an exception, or
\item%
when initialization of a non-local
variable with static or thread storage duration~(\ref{basic.start.init})
exits via an exception, or
\item%
when destruction of an object with static or thread storage duration exits
via an exception~(\ref{basic.start.term}), or
\item%
when execution of a function registered with
\tcode{std::atexit} or \tcode{std::at_quick_exit}
exits via an exception~(\ref{support.start.term}), or
\item%
when a
\grammarterm{throw-expression}
with no operand attempts to rethrow an exception and no exception is being
handled~(\ref{except.throw}), or
\item%
when
\tcode{std::unexpected}
throws an exception which is not allowed by the previously violated
\grammarterm{dynamic-exception-specification},
and
\tcode{std::bad_exception}
is not included in that
\grammarterm{dynamic-exception-specifica\brk{-}tion} (\ref{except.unexpected}), or
\item%
when the implementation's default
unexpected exception handler
is called~(\ref{unexpected.handler}), or
\item%
when the function \tcode{std::nested_exception::rethrow_nested} is called for an object
that has captured no exception~(\ref{except.nested}), or
\item%
when execution of the initial function of a thread exits via
an exception~(\ref{thread.thread.constr}), or
\item%
when the destructor or the copy assignment operator is invoked on an object
of type \tcode{std::thread} that refers to a joinable thread
(\ref{thread.thread.destr},~\ref{thread.thread.assign}).
\end{itemize}
\exitnote
\pnum
\indextext{\idxcode{terminate()}}%
In such cases,
\tcode{std::terminate()}
is called~(\ref{exception.terminate}).
In the situation where no matching handler is found, it is
\impldef{stack unwinding before call to \tcode{std::terminate()}} whether or not the
stack is unwound
before
\tcode{std::terminate()}
is called.
In the situation where the search for a handler~(\ref{except.handle}) encounters the
outermost block of a function with a \grammarterm{noexcept-specification}
that does not allow the exception~(\ref{except.spec}), it is
\impldef{whether stack is unwound before calling \tcode{std::terminate()}
when a \tcode{noexcept} specification
is violated}
whether the stack is unwound, unwound partially, or not unwound at all
before \tcode{std::terminate()} is called.
In all other situations, the stack shall not be unwound before
\tcode{std::terminate()}
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
\tcode{std::terminate()}.
\rSec2[except.unexpected]{The \tcode{std::unexpected()} function}
\pnum
\indextext{\idxcode{unexpected()}}%
If a function with
a \grammarterm{dynamic-exception-specification}
throws an exception that is not listed in the
\grammarterm{ dynamic-exception-specification},
the function
\tcode{std::unexpected()}
is called~(\ref{exception.unexpected}) immediately after completing
the stack unwinding for the former function.
\pnum
\enternote By default, \tcode{std::unexpected()} calls \tcode{std::terminate()}, but a
program can install its own handler function~(\ref{set.unexpected}). In either case, the
constraints in the following paragraph apply. \exitnote
\pnum
The
\tcode{std::unexpected()}
function shall not return, but it can throw (or re-throw) an exception.
If it throws a new exception which is allowed by the exception specification
which previously was violated, then the search for another handler
will continue at the call of the function whose exception specification was violated.
If it throws or rethrows an exception that the
\grammarterm{ dynamic-exception-specification}
does not allow
then the following happens:
\indextext{\idxcode{bad_exception}}%
If the
\grammarterm{ dynamic-exception-specification}
does not include the class
\tcode{std::bad_exception}~(\ref{bad.exception})
then the function
\tcode{std::terminate()}
is called, otherwise the thrown exception is replaced by an
implementation-defined object of the type
\tcode{std::bad_exception}
and the search for another handler will continue at the call of the function
whose
\grammarterm{ dynamic-exception-specification}
was violated.
\pnum
Thus,
a \grammarterm{dynamic-exception-specification}
guarantees that only the listed exceptions will be thrown.
If the
\grammarterm{ dynamic-exception-specification}
includes the type
\tcode{std::bad_exception}
then any exception not on the list may be replaced by
\tcode{std\-::\-bad_ex\-cep\-tion}
within the function
\tcode{std::unexpected()}.
\rSec2[except.uncaught]{The \tcode{std::uncaught_exception()} function}%
\indextext{\idxcode{uncaught_exception()}}
\pnum
The function
\tcode{std::uncaught_exception()}
returns
\tcode{true}
after completing
the initialization of the exception object~(\ref{except.throw})
until completing
the
activation of a handler for the exception~(\ref{except.handle},~\ref{uncaught}).
This includes stack unwinding.
If the exception is rethrown~(\ref{except.throw}),
\tcode{std::uncaught_exception()}
returns
\tcode{true}
from the point of rethrow until the rethrown exception is caught again.%
\indextext{exception handling|)}
Jump to Line
Something went wrong with that request. Please try again.