[except] - C++14 → C++17

Files changed (1) hide show

tmp/tmp_l39h7hi/{from.md → to.md} +399 -440

tmp/tmp_l39h7hi/{from.md → to.md} RENAMED Viewed

@@ -32,46 +32,48 @@ exception-declaration:
     attribute-specifier-seqₒₚₜ type-specifier-seq declarator
     attribute-specifier-seqₒₚₜ type-specifier-seq abstract-declaratorₒₚₜ
     '...'
 ```
-``` bnf
-throw-expression:
-    'throw' assignment-expressionₒₚₜ
-```
 The optional *attribute-specifier-seq* in an *exception-declaration*
 appertains to the parameter of the catch clause ([[except.handle]]).
-A *try-block* is a *statement* (Clause  [[stmt.stmt]]). A
-*throw-expression* is of type `void`. Within this Clause “try block” is
-taken to mean both *try-block* and *function-try-block*.
 A `goto` or `switch` statement shall not be used to transfer control
 into a try block or into a handler.
 ``` cpp
 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
   }
 }
 ```
 A `goto`, `break`, `return`, or `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.
 ``` cpp
 lab:  try {
   T1 t1;
   try {
     T2 t2;
@@ -80,23 +82,27 @@ lab:  try {
     } catch(...) { /* handler 2 */ }
   } catch(...) { /* handler 1 */ }
 ```
 Here, executing `goto lab;` will destroy first `t2`, then `t1`, assuming
-the *condition* does not declare a variable. Any exception raised while
-destroying `t2` will result in executing *handler 2*; any exception
-raised while destroying `t1` will result in executing *handler 1*.
 A *function-try-block* associates a *handler-seq* with the
 *ctor-initializer*, if present, and the *compound-statement*. An
 exception thrown during the execution of the *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 *function-try-block* in the same way as an exception
 thrown during the execution of a *try-block* transfers control to other
 handlers.
 ``` cpp
 int f(int);
 class C {
   int i;
   double d;
@@ -105,38 +111,46 @@ public:
 };
 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
 }
 ```
 ## Throwing an exception <a id="except.throw">[[except.throw]]</a>
-Throwing an exception transfers control to a handler. An exception can
-be thrown from one of the following contexts: *throw-expression* (see
-below), allocation functions ([[basic.stc.dynamic.allocation]]),
-`dynamic_cast` ([[expr.dynamic.cast]]), `typeid` ([[expr.typeid]]),
-*new-expression* ([[expr.new]]), and standard library functions (
-[[structure.specifications]]). An object is passed and the type of that
-object determines which handlers can catch it.
 ``` cpp
 throw "Help!";
 ```
 can be caught by a *handler* of `const` `char*` type:
 ``` cpp
 try {
     // ...
-}
-catch(const char* p) {
     // handle character string exceptions here
 }
 ```
 and
@@ -150,73 +164,87 @@ public:
 void f(double x) {
     throw Overflow('+',x,3.45e107);
 }
 ```
-can be caught by a handler for exceptions of type `Overflow`
 ``` cpp
 try {
     f(1.2);
 } catch(Overflow& oo) {
     // handle exceptions of type Overflow here
 }
 ```
 When an exception is thrown, control is transferred to the nearest
 handler with a matching type ([[except.handle]]); “nearest” means the
 handler for which the *compound-statement* or *ctor-initializer*
 following the `try` keyword was most recently entered by the thread of
 control and not yet exited.
 Throwing an exception copy-initializes ([[dcl.init]], [[class.copy]]) a
-temporary object, called the *exception object*. The temporary is an
-lvalue and is used to initialize the variable declared in the matching
 *handler* ([[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) `void` the program is ill-formed.
-Evaluating a *throw-expression* with an operand throws an exception; the
-type of the exception object is determined by removing any top-level
-*cv-qualifiers* from the static type of the operand and adjusting the
-type from “array of `T`” or “function returning `T`” to “pointer to `T`”
-or “pointer to function returning `T`,” respectively.
 The memory for the exception object is allocated in an unspecified way,
 except as noted in  [[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 `std::exception_ptr` (
-[[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 *exception-declaration* in the handler, if any. In the latter
-case, the destruction occurs before the destructor of
-`std::exception_ptr` returns. The implementation may then deallocate the
-memory for the exception object; any such deallocation is done in an
-unspecified way. a thrown exception does not propagate to other threads
 unless caught, stored, and rethrown using appropriate library functions;
-see  [[propagation]] and  [[futures]].
 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 ([[class.copy]]).
 An exception is considered caught when a handler for that exception
-becomes active ([[except.handle]]). An exception can have active
-handlers and still be considered uncaught if it is rethrown.
-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,
-`std::terminate` is called ([[except.terminate]]).
 ``` cpp
 struct C {
   C() { }
   C(const C&) {
-    if (std::uncaught_exception()) {
       throw 0;      // throw during copy to handler's exception-declaration object~([except.handle])
     }
   }
 };
@@ -226,58 +254,76 @@ int main() {
                     // exception-declaration object is not elided~([class.copy])
   } catch(C) { }
 }
 ```
-A *throw-expression* with no operand rethrows the currently handled
-exception ([[except.handle]]). The exception is reactivated with the
-existing exception object; no new exception object is created. The
-exception is no longer considered to be caught; therefore, the value of
-`std::uncaught_exception()` will again be `true`. code that must be
-executed because of an exception yet cannot completely handle the
-exception can be written like this:
-``` cpp
-try {
-    // ...
-} catch (...) {     // catch all exceptions
-  // respond (partially) to exception
-  throw;            // pass the exception to some
-                    // other handler
-}
-```
-If no exception is presently being handled, executing a
-*throw-expression* with no operand calls `std::terminate()` (
-[[except.terminate]]).
 ## Constructors and destructors <a id="except.ctor">[[except.ctor]]</a>
 As control passes from the point where an exception is thrown 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 ([[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
-*new-expression*, the matching deallocation function (
-[[basic.stc.dynamic.deallocation]], [[expr.new]], [[class.free]]), if
-any, is called to free the storage occupied by the object.
-The process of calling destructors for automatic objects constructed on
-the path from a try block to the point where an exception is thrown is
-called “*stack unwinding*.” If a destructor called during stack
-unwinding exits with an exception, `std::terminate` is called (
-[[except.terminate]]). So destructors should generally catch exceptions
-and not let them propagate out of the destructor.
 ## Handling an exception <a id="except.handle">[[except.handle]]</a>
 The *exception-declaration* in a *handler* describes the type(s) of
 exceptions that can cause that *handler* to be entered. The
@@ -285,37 +331,41 @@ exceptions that can cause that *handler* to be entered. The
 class type, or an rvalue reference type. The *exception-declaration*
 shall not denote a pointer or reference to an incomplete type, other
 than `void*`, `const` `void*`, `volatile` `void*`, or `const` `volatile`
 `void*`.
-A handler of type “array of `T`” or “function returning `T`” is adjusted
-to be of type “pointer to `T`” or “pointer to function returning `T`”,
-respectively.
 A *handler* is a match for an exception object of type `E` if
-- The *handler* is of type *cv* `T` or *cv* `T&` and `E` and `T` are the
-  same type (ignoring the top-level *cv-qualifiers*), or
-- the *handler* is of type *cv* `T` or *cv* `T&` and `T` is an
- unambiguous public base class of `E`, or
-- the *handler* is of type *cv* `T` or `const T&` where `T` is a pointer
-  type and `E` is a pointer type that can be converted to `T` by either
-  or both of
   - a standard pointer conversion ([[conv.ptr]]) not involving
     conversions to pointers to private or protected or ambiguous classes
-  - a qualification conversion, or
-- the *handler* is of type *cv* `T` or `const T&` where `T` is a pointer
   or pointer to member type and `E` is `std::nullptr_t`.
-A *throw-expression* whose operand is an integer literal with value zero
-does not match a handler of pointer or pointer to member type.
 ``` cpp
-class Matherr { /* ... */ virtual void vf(); };
-class Overflow: public Matherr { /* ... */ };
-class Underflow: public Matherr { /* ... */ };
-class Zerodivide: public Matherr { /* ... */ };
 void f() {
   try {
     g();
   } catch (Overflow oo) {
@@ -329,14 +379,18 @@ void f() {
 Here, the `Overflow` handler will catch exceptions of type `Overflow`
 and the `Matherr` handler will catch exceptions of type `Matherr` and of
 all types publicly derived from `Matherr` including exceptions of type
 `Underflow` and `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 `...` in a handler’s *exception-declaration* functions similarly to
 `...` in a function parameter declaration; it specifies a match for any
 exception. If present, a `...` handler shall be the last handler for its
 try block.
@@ -344,15 +398,18 @@ 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
-`std::terminate()` or `std::unexpected()` is entered due to a throw. A
-handler is no longer considered active when the catch clause exits or
-when `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 *currently handled exception*.
 If no matching handler is found, the function `std::terminate()` is
@@ -361,44 +418,32 @@ called; whether or not the stack is unwound before this call to
 Referring to any non-static member or base class of an object in the
 handler for a *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 *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 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 of a destructor for that
-object ([[class.dtor]]).
 The scope and lifetime of the parameters of a function or constructor
 extend into the handlers of a *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 *function-try-block* on `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 *function-try-block* on the initial
-function of the thread.
 If a return statement appears in a handler of the *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 *function-try-block* of a constructor or destructor.
-Otherwise, a function returns when control reaches the end of a handler
-for the *function-try-block* ([[stmt.return]]). Flowing off the end of
-a *function-try-block* is equivalent to a `return` with no value; this
-results in undefined behavior in a value-returning function (
-[[stmt.return]]).
-The variable declared by the *exception-declaration*, of type cv `T` or
-cv `T&`, is initialized from the exception object, of type `E`, as
 follows:
 - if `T` is a base class of `E`, the variable is copy-initialized (
   [[dcl.init]]) from the corresponding base class subobject of the
   exception object;
@@ -413,428 +458,342 @@ 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.
 ## Exception specifications <a id="except.spec">[[except.spec]]</a>
-A function declaration lists exceptions that its function might directly
-or indirectly throw by using an *exception-specification* as a suffix of
-its declarator.
 ``` bnf
-exception-specification:
-    dynamic-exception-specification
-    noexcept-specification
-```
-``` bnf
-dynamic-exception-specification:
-    'throw (' type-id-listₒₚₜ ')'
-```
-``` bnf
-type-id-list:
-    type-id '...'ₒₚₜ
-    type-id-list ',' type-id '...'ₒₚₜ
-```
-``` bnf
-noexcept-specification:
     'noexcept' '(' constant-expression ')'
     'noexcept'
 ```
-In a *noexcept-specification*, the *constant-expression*, if supplied,
-shall be a constant expression ([[expr.const]]) that is contextually
-converted to `bool` (Clause  [[conv]]). A *noexcept-specification*
-`noexcept` is equivalent to `noexcept(true)`. A `(` token that follows
-`noexcept` is part of the *noexcept-specification* and does not commence
-an initializer ([[dcl.init]]).
-An *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 *exception-specification* shall
-not appear in a typedef declaration or *alias-declaration*.
-``` cpp
-void f() throw(int);                    // OK
-void (*fp)() throw (int);               // OK
-void g(void pfa() throw(int));          // OK
-typedef int (*pf)() throw(int);         // ill-formed
-```
-A type denoted in an *exception-specification* shall not denote an
-incomplete type or an rvalue reference type. A type denoted in an
-*exception-specification* shall not denote a pointer or reference to an
-incomplete type, other than *cv* `void*`. A type cv `T`, “array of `T`”,
-or “function returning `T`” denoted in an *exception-specification* is
-adjusted to type `T`, “pointer to `T`”, or “pointer to function
-returning `T`”, respectively.
-Two *exception-specification*s are *compatible* if:
-- both are non-throwing (see below), regardless of their form,
-- both have the form `noexcept(`*constant-expression*`)` and the
-  *constant-expression*s are equivalent, or
-- both are *dynamic-exception-specification*s that have the same set of
-  adjusted types.
-If any declaration of a function has an *exception-specification* that
-is not a *noexcept-specification* allowing all exceptions, all
-declarations, including the definition and any explicit specialization,
-of that function shall have a compatible *exception-specification*. If
-any declaration of a pointer to function, reference to function, or
-pointer to member function has an *exception-specification*, all
-occurrences of that declaration shall have a compatible
-*exception-specification* In an explicit instantiation an
-*exception-specification* may be specified, but is not required. If an
-*exception-specification* is specified in an explicit instantiation
-directive, it shall be compatible with the *exception-specification*s of
-other declarations of that function. A diagnostic is required only if
-the *exception-specification*s are not compatible within a single
-translation unit.
-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.
 ``` cpp
 struct B {
-  virtual void f() throw (int, double);
   virtual void g();
 };
 struct D: B {
   void f();                     // ill-formed
-  void g() throw (int); // OK
 };
 ```
-The declaration of `D::f` is ill-formed because it allows all
-exceptions, whereas `B::f` allows only `int` and `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.
-``` cpp
-class A { /* ... */ };
-void (*pf1)();      // no exception specification
-void (*pf2)() throw(A);
-void f() {
-  pf1 = pf2;        // OK: pf1 is less restrictive
-  pf2 = pf1;        // error: pf2 is more restrictive
-}
-```
-In such an assignment or initialization, *exception-specification*s on
-return types and parameter types shall be compatible. In other
-assignments or initializations, *exception-specification*s shall be
-compatible.
-An *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. An *exception-specification* can also include the
-class `std::bad_exception` ([[bad.exception]]).
-A function is said to *allow* an exception of type `E` if the
-*constant-expression* in its *noexcept-specification* evaluates to
-`false` or its *dynamic-exception-specification* contains a type `T` for
-which a handler of type `T` would be a match ([[except.handle]]) for an
-exception of type `E`.
 Whenever an exception is thrown and the search for a handler (
-[[except.handle]]) encounters the outermost block of a function with an
-*exception-specification* that does not allow the exception, then,
-- if the *exception-specification* is a
-  *dynamic-exception-specification*, the function `std::unexpected()` is
-  called ([[except.unexpected]]),
-- otherwise, the function `std::terminate()` is called (
- [[except.terminate]]).
 ``` cpp
-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 std::unexpected()
 }
 ```
-A function can have multiple declarations with different non-throwing
-*exception-specification*s; for this purpose, the one on the function
-definition is used.
-The function `unexpected()` may throw an exception that will satisfy the
-*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 *exception-specification* (see  [[except.unexpected]]), or it
-may call `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.
-``` cpp
-extern void f() throw(X, Y);
-void g() throw(X) {
-  f();                          // OK
-}
-```
-the call to `f` is well-formed even though when called, `f` might throw
-exception `Y` that `g` does not allow.
-A function with no *exception-specification* or with an
-*exception-specification* of the form
-`noexcept(`*constant-expression*`)` where the *constant-expression*
-yields `false` allows all exceptions. An *exception-specification* is
-*non-throwing* if it is of the form `throw()`, `noexcept`, or
-`noexcept(`*constant-expression*`)` where the *constant-expression*
-yields `true`. A function with a non-throwing *exception-specification*
-does not allow any exceptions.
-An *exception-specification* is not considered part of a function’s
-type.
-An inheriting constructor ([[class.inhctor]]) and an implicitly
-declared special member function (Clause  [[special]]) have an
-*exception-specification*. If `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 *exception-specification* specifies the *type-id*
-`T` if and only if `T` is allowed by the *exception-specification* of a
-function directly invoked by `f`’s implicit definition; `f` allows all
-exceptions if any function it directly invokes allows all exceptions,
-and `f` has the *exception-specification* `noexcept(true)` if every
-function it directly invokes allows no exceptions. It follows that `f`
-has the *exception-specification* `noexcept(true)` if it invokes no
-other functions. An instantiation of an inheriting constructor template
-has an implied *exception-specification* as if it were a non-template
-inheriting constructor.
 ``` cpp
 struct A {
-  A();
-  A(const A&) throw();
-  A(A&&) throw();
-  ~A() throw(X);
 };
 struct B {
   B() throw();
-  B(const B&) = default; // Declaration of B::B(const B&) noexcept(true)
-  B(B&&) throw(Y);
-  ~B() throw(Y);
 };
 struct D : public A, public B {
- // Implicit declaration of D::D();
-    // Implicit declaration of D::D(const D&) noexcept(true);
-    // Implicit declaration of D::D(D&&) throw(Y);
-    // Implicit declaration of D::~D() throw(X, Y);
 };
 ```
-Furthermore, if `A::~A()` or `B::~B()` were virtual, `D::~D()` would not
-be as restrictive as that of `A::~A`, and the program would be
-ill-formed since a function that overrides a virtual function from a
-base class shall have an *exception-specification* at least as
-restrictive as that in the base class.
-A deallocation function ([[basic.stc.dynamic.deallocation]]) with no
-explicit *exception-specification* is treated as if it were specified
-with `noexcept(true)`.
-An *exception-specification* is considered to be *needed* when:
 - in an expression, the function is the unique lookup result or the
   selected member of a set of overloaded functions ([[basic.lookup]],
   [[over.match]], [[over.over]]);
 - the function is odr-used ([[basic.def.odr]]) or, if it appears in an
   unevaluated operand, would be odr-used if the expression were
   potentially-evaluated;
-- the *exception-specification* is compared to that of another
- declaration (e.g., an explicit specialization or an overriding virtual
-  function);
 - the function is defined; or
-- the *exception-specification* is needed for a defaulted special member
-  function that calls the function. A defaulted declaration does not
-  require the *exception-specification* of a base member function to be
-  evaluated until the implicit *exception-specification* of the derived
-  function is needed, but an explicit *exception-specification* needs
-  the implicit *exception-specification* to compare against.
-The *exception-specification* of a defaulted special member function is
 evaluated as described above only when needed; similarly, the
-*exception-specification* of a specialization of a function template or
 member function of a class template is instantiated only when needed.
-In a *dynamic-exception-specification*, a *type-id* followed by an
-ellipsis is a pack expansion ([[temp.variadic]]).
-The use of *dynamic-exception-specification*s is deprecated (see Annex
-[[depr]]).
 ## Special functions <a id="except.special">[[except.special]]</a>
-The functions `std::terminate()` ([[except.terminate]]) and
-`std::unexpected()` ([[except.unexpected]]) are used by the exception
-handling mechanism for coping with errors related to the exception
-handling mechanism itself. The function `std::current_exception()` (
-[[propagation]]) and the class `std::nested_exception` (
-[[except.nested]]) can be used by a program to capture the currently
-handled exception.
 ### The `std::terminate()` function <a id="except.terminate">[[except.terminate]]</a>
 In some situations exception handling must be abandoned for less subtle
-error handling techniques. These situations are:
 - when the exception handling mechanism, after completing the
   initialization of the exception object but before activation of a
   handler for the exception ([[except.throw]]), calls a function that
   exits via an exception, or
 - when the exception handling mechanism cannot find a handler for a
   thrown exception ([[except.handle]]), or
 - when the search for a handler ([[except.handle]]) encounters the
-  outermost block of a function with a *noexcept-specification* that
- does not allow the exception ([[except.spec]]), or
 - when the destruction of an object during stack unwinding (
   [[except.ctor]]) terminates by throwing an exception, or
 - when initialization of a non-local variable with static or thread
-  storage duration ([[basic.start.init]]) exits via an exception, or
 - when destruction of an object with static or thread storage duration
   exits via an exception ([[basic.start.term]]), or
 - when execution of a function registered with `std::atexit` or
   `std::at_quick_exit` exits via an exception ([[support.start.term]]),
   or
-- when a *throw-expression* with no operand attempts to rethrow an
-  exception and no exception is being handled ([[except.throw]]), or
-- when `std::unexpected` throws an exception which is not allowed by the
-  previously violated *dynamic-exception-specification*, and
-  `std::bad_exception` is not included in that
-  *dynamic-exception-specifica{-}tion* ([[except.unexpected]]), or
-- when the implementation’s default unexpected exception handler is
-  called ([[unexpected.handler]]), or
 - when the function `std::nested_exception::rethrow_nested` is called
   for an object that has captured no exception ([[except.nested]]), or
 - when execution of the initial function of a thread exits via an
   exception ([[thread.thread.constr]]), or
 - when the destructor or the copy assignment operator is invoked on an
   object of type `std::thread` that refers to a joinable thread (
-  [[thread.thread.destr]],  [[thread.thread.assign]]).
 In such cases, `std::terminate()` is called ([[exception.terminate]]).
 In the situation where no matching handler is found, it is
 *implementation-defined* whether or not the stack is unwound before
 `std::terminate()` is called. In the situation where the search for a
 handler ([[except.handle]]) encounters the outermost block of a
-function with a *noexcept-specification* that does not allow the
-exception ([[except.spec]]), it is *implementation-defined* whether the
-stack is unwound, unwound partially, or not unwound at all before
-`std::terminate()` is called. In all other situations, the stack shall
-not be unwound before `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
-`std::terminate()`.
-### The `std::unexpected()` function <a id="except.unexpected">[[except.unexpected]]</a>
-If a function with a *dynamic-exception-specification* throws an
-exception that is not listed in the * dynamic-exception-specification*,
-the function `std::unexpected()` is called ([[exception.unexpected]])
-immediately after completing the stack unwinding for the former
-function.
-By default, `std::unexpected()` calls `std::terminate()`, but a program
-can install its own handler function ([[set.unexpected]]). In either
-case, the constraints in the following paragraph apply.
-The `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 * dynamic-exception-specification* does not allow
-then the following happens: If the * dynamic-exception-specification*
-does not include the class `std::bad_exception` ([[bad.exception]])
-then the function `std::terminate()` is called, otherwise the thrown
-exception is replaced by an implementation-defined object of the type
-`std::bad_exception` and the search for another handler will continue at
-the call of the function whose * dynamic-exception-specification* was
-violated.
-Thus, a *dynamic-exception-specification* guarantees that only the
-listed exceptions will be thrown. If the
-* dynamic-exception-specification* includes the type
-`std::bad_exception` then any exception not on the list may be replaced
-by `std::bad_exception` within the function `std::unexpected()`.
-### The `std::uncaught_exception()` function <a id="except.uncaught">[[except.uncaught]]</a>
-The function `std::uncaught_exception()` returns `true` after completing
-the initialization of the exception object ([[except.throw]]) until
-completing the activation of a handler for the exception (
-[[except.handle]],  [[uncaught]]). This includes stack unwinding. If the
-exception is rethrown ([[except.throw]]), `std::uncaught_exception()`
-returns `true` from the point of rethrow until the rethrown exception is
-caught again.
 <!-- Link reference definitions -->
-[bad.exception]: language.md#bad.exception
 [basic.def.odr]: basic.md#basic.def.odr
 [basic.lookup]: basic.md#basic.lookup
-[basic.start.init]: basic.md#basic.start.init
 [basic.start.term]: basic.md#basic.start.term
 [basic.stc.dynamic.allocation]: basic.md#basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: basic.md#basic.stc.dynamic.deallocation
-[class.base.init]: special.md#class.base.init
 [class.copy]: special.md#class.copy
 [class.dtor]: special.md#class.dtor
-[class.free]: special.md#class.free
-[class.inhctor]: special.md#class.inhctor
-[conv]: conv.md#conv
 [conv.ptr]: conv.md#conv.ptr
 [dcl.init]: dcl.md#dcl.init
-[depr]: future.md#depr
 [except]: #except
 [except.ctor]: #except.ctor
 [except.handle]: #except.handle
 [except.nested]: language.md#except.nested
 [except.spec]: #except.spec
 [except.special]: #except.special
 [except.terminate]: #except.terminate
 [except.throw]: #except.throw
 [except.uncaught]: #except.uncaught
-[except.unexpected]: #except.unexpected
 [exception.terminate]: language.md#exception.terminate
-[exception.unexpected]: future.md#exception.unexpected
 [expr.const]: expr.md#expr.const
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.new]: expr.md#expr.new
 [expr.typeid]: expr.md#expr.typeid
 [futures]: thread.md#futures
 [over.match]: over.md#over.match
 [over.over]: over.md#over.over
 [propagation]: language.md#propagation
-[set.unexpected]: future.md#set.unexpected
-[special]: special.md#special
 [stmt.return]: stmt.md#stmt.return
 [stmt.stmt]: stmt.md#stmt.stmt
 [structure.specifications]: library.md#structure.specifications
 [support.start.term]: language.md#support.start.term
-[temp.variadic]: temp.md#temp.variadic
 [thread.thread.assign]: thread.md#thread.thread.assign
 [thread.thread.constr]: thread.md#thread.thread.constr
 [thread.thread.destr]: thread.md#thread.thread.destr
-[uncaught]: language.md#uncaught
-[unexpected.handler]: future.md#unexpected.handler

     attribute-specifier-seqₒₚₜ type-specifier-seq declarator
     attribute-specifier-seqₒₚₜ type-specifier-seq abstract-declaratorₒₚₜ
     '...'
 ```
 The optional *attribute-specifier-seq* in an *exception-declaration*
 appertains to the parameter of the catch clause ([[except.handle]]).
+A *try-block* is a *statement* (Clause  [[stmt.stmt]]).
+[*Note 1*: Within this Clause “try block” is taken to mean both
+*try-block* and *function-try-block*. — *end note*]
 A `goto` or `switch` statement shall not be used to transfer control
 into a try block or into a handler.
+[*Example 1*:
 ``` cpp
 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 example*]
 A `goto`, `break`, `return`, or `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.
+[*Example 2*:
 ``` cpp
 lab:  try {
   T1 t1;
   try {
     T2 t2;
     } catch(...) { /* handler 2 */ }
   } catch(...) { /* handler 1 */ }
 ```
 Here, executing `goto lab;` will destroy first `t2`, then `t1`, assuming
+the *condition* does not declare a variable. Any exception thrown while
+destroying `t2` will result in executing `handler 2`; any exception
+thrown while destroying `t1` will result in executing `handler 1`.
+— *end example*]
 A *function-try-block* associates a *handler-seq* with the
 *ctor-initializer*, if present, and the *compound-statement*. An
 exception thrown during the execution of the *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 *function-try-block* in the same way as an exception
 thrown during the execution of a *try-block* transfers control to other
 handlers.
+[*Example 3*:
 ``` cpp
 int f(int);
 class C {
   int i;
   double d;
 };
 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 example*]
+In this section, “before” and “after” refer to the “sequenced before”
+relation ([[intro.execution]]).
 ## Throwing an exception <a id="except.throw">[[except.throw]]</a>
+Throwing an exception transfers control to a handler.
+[*Note 1*: An exception can be thrown from one of the following
+contexts: *throw-expression*s ([[expr.throw]]), allocation functions (
+[[basic.stc.dynamic.allocation]]), `dynamic_cast` (
+[[expr.dynamic.cast]]), `typeid` ([[expr.typeid]]), *new-expression*s (
+[[expr.new]]), and standard library functions (
+[[structure.specifications]]). — *end note*]
+An object is passed and the type of that object determines which
+handlers can catch it.
+[*Example 1*:
 ``` cpp
 throw "Help!";
 ```
 can be caught by a *handler* of `const` `char*` type:
 ``` cpp
 try {
     // ...
+} catch(const char* p) {
     // handle character string exceptions here
 }
 ```
 and
 void f(double x) {
     throw Overflow('+',x,3.45e107);
 }
 ```
+can be caught by a handler for exceptions of type `Overflow`:
 ``` cpp
 try {
     f(1.2);
 } catch(Overflow& oo) {
     // handle exceptions of type Overflow here
 }
 ```
+— *end example*]
 When an exception is thrown, control is transferred to the nearest
 handler with a matching type ([[except.handle]]); “nearest” means the
 handler for which the *compound-statement* or *ctor-initializer*
 following the `try` keyword was most recently entered by the thread of
 control and not yet exited.
 Throwing an exception copy-initializes ([[dcl.init]], [[class.copy]]) a
+temporary object, called the *exception object*. An lvalue denoting the
+temporary is used to initialize the variable declared in the matching
 *handler* ([[except.handle]]). If the type of the exception object
 would be an incomplete type or a pointer to an incomplete type other
+than cv `void` the program is ill-formed.
 The memory for the exception object is allocated in an unspecified way,
 except as noted in  [[basic.stc.dynamic.allocation]]. If a handler exits
 by rethrowing, control is passed to another handler for the same
+exception object. The points of potential destruction for the exception
+object are:
+- when an active handler for the exception exits by any means other than
+  rethrowing, immediately after the destruction of the object (if any)
+  declared in the *exception-declaration* in the handler;
+- when an object of type `std::exception_ptr` ([[propagation]]) that
+  refers to the exception object is destroyed, before the destructor of
+ `std::exception_ptr` returns.
+Among all points of potential destruction for the exception object,
+there is an unspecified last one where the exception object is
+destroyed. All other points happen before that last one (
+[[intro.races]]).
+[*Note 2*: No other thread synchronization is implied in exception
+handling. — *end note*]
+The implementation may then deallocate the memory for the exception
+object; any such deallocation is done in an unspecified way.
+[*Note 3*: A thrown exception does not propagate to other threads
 unless caught, stored, and rethrown using appropriate library functions;
+see  [[propagation]] and  [[futures]]. — *end note*]
 When the thrown object is a class object, the constructor selected for
+the copy-initialization as well as the constructor selected for a
+copy-initialization considering the thrown object as an lvalue shall be
+non-deleted and accessible, even if the copy/move operation is elided (
+[[class.copy]]). The destructor is potentially invoked (
+[[class.dtor]]).
 An exception is considered caught when a handler for that exception
+becomes active ([[except.handle]]).
+[*Note 4*: An exception can have active handlers and still be
+considered uncaught if it is rethrown. — *end note*]
+If the exception handling mechanism handling an uncaught exception (
+[[except.uncaught]]) directly invokes a function that exits via an
+exception, `std::terminate` is called ([[except.terminate]]).
+[*Example 2*:
 ``` cpp
 struct C {
   C() { }
   C(const C&) {
+    if (std::uncaught_exceptions()) {
       throw 0;      // throw during copy to handler's exception-declaration object~([except.handle])
     }
   }
 };
                     // exception-declaration object is not elided~([class.copy])
   } catch(C) { }
 }
 ```
+— *end example*]
+[*Note 5*: Consequently, destructors should generally catch exceptions
+and not let them propagate. — *end note*]
 ## Constructors and destructors <a id="except.ctor">[[except.ctor]]</a>
 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 *stack unwinding*.
+The destructor is invoked for each automatic object of class type
+constructed, but not yet destroyed, since the try block was entered. If
+an exception is thrown during the destruction of temporaries or local
+variables for a `return` statement ([[stmt.return]]), the destructor
+for the returned object (if any) is also invoked. The objects are
+destroyed in the reverse order of the completion of their construction.
+[*Example 1*:
+``` cpp
+struct A { };
+struct Y { ~Y() noexcept(false) { throw 0; } };
+A f() {
+ try {
+    A a;
+    Y y;
+    A b;
+    return {};      // #1
+  } catch (...) {
+  }
+  return {};        // #2
+}
+```
+At \#1, the returned object of type `A` is constructed. Then, the local
+variable `b` is destroyed ([[stmt.jump]]). Next, the local variable `y`
+is destroyed, causing stack unwinding, resulting in the destruction of
+the returned object, followed by the destruction of the local variable
+`a`. Finally, the returned object is constructed again at \#2.
+— *end example*]
+If the initialization or destruction of an object other than by
+delegating constructor is terminated by an exception, the destructor is
+invoked for each of the object’s direct subobjects and, for a complete
+object, virtual base class subobjects, whose initialization has
+completed ([[dcl.init]]) and whose 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
+*function-try-block* of the constructor or destructor, if any.
+If the *compound-statement* of the *function-body* of a delegating
+constructor for an object exits via an exception, the object’s
+destructor is invoked. Such destruction is sequenced before entering a
+handler of the *function-try-block* of a delegating constructor for that
+object, if any.
+[*Note 1*: If the object was allocated by a *new-expression* (
+[[expr.new]]), the matching deallocation function (
+[[basic.stc.dynamic.deallocation]]), if any, is called to free the
+storage occupied by the object. — *end note*]
 ## Handling an exception <a id="except.handle">[[except.handle]]</a>
 The *exception-declaration* in a *handler* describes the type(s) of
 exceptions that can cause that *handler* to be entered. The
 class type, or an rvalue reference type. The *exception-declaration*
 shall not denote a pointer or reference to an incomplete type, other
 than `void*`, `const` `void*`, `volatile` `void*`, or `const` `volatile`
 `void*`.
+A handler of type “array of `T`” or function type `T` is adjusted to be
+of type “pointer to `T`”.
 A *handler* is a match for an exception object of type `E` if
+- The *handler* is of type cv `T` or cv `T&` and `E` and `T` are the
+  same type (ignoring the top-level *cv-qualifier*s), or
+- the *handler* is of type cv `T` or cv `T&` and `T` is an unambiguous
+  public base class of `E`, or
+- the *handler* is of type cv `T` or `const T&` where `T` is a pointer
+ or pointer to member type and `E` is a pointer or pointer to member
+ type that can be converted to `T` by one or more of
   - a standard pointer conversion ([[conv.ptr]]) not involving
     conversions to pointers to private or protected or ambiguous classes
+  - a function pointer conversion ([[conv.fctptr]])
+ - a qualification conversion ([[conv.qual]]), or
+- the *handler* is of type cv `T` or `const T&` where `T` is a pointer
   or pointer to member type and `E` is `std::nullptr_t`.
+[*Note 1*: A *throw-expression* whose operand is an integer literal
+with value zero does not match a handler of pointer or pointer to member
+type. A handler of reference to array or function type is never a match
+for any exception object ([[expr.throw]]). — *end note*]
+[*Example 1*:
 ``` cpp
+class Matherr { ... virtual void vf(); };
+class Overflow: public Matherr { ... };
+class Underflow: public Matherr { ... };
+class Zerodivide: public Matherr { ... };
 void f() {
   try {
     g();
   } catch (Overflow oo) {
 Here, the `Overflow` handler will catch exceptions of type `Overflow`
 and the `Matherr` handler will catch exceptions of type `Matherr` and of
 all types publicly derived from `Matherr` including exceptions of type
 `Underflow` and `Zerodivide`.
+— *end example*]
+The handlers for a try block are tried in order of appearance.
+[*Note 2*: This makes it possible to write handlers that can never be
+executed, for example by placing a handler for a final derived class
+after a handler for a corresponding unambiguous public base
+class. — *end note*]
 A `...` in a handler’s *exception-declaration* functions similarly to
 `...` in a function parameter declaration; it specifies a match for any
 exception. If present, a `...` 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.
+[*Note 3*: The stack will have been unwound at that
+point. — *end note*]
+Also, an implicit handler is considered active when `std::terminate()`
+is entered due to a throw. A handler is no longer considered active when
+the catch clause exits.
 The exception with the most recently activated handler that is still
 active is called the *currently handled exception*.
 If no matching handler is found, the function `std::terminate()` is
 Referring to any non-static member or base class of an object in the
 handler for a *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 *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 *function-try-block* on the `main`
+function ([[basic.start.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
+*function-try-block* on the initial function of the thread.
 If a return statement appears in a handler of the *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 *function-try-block* of a constructor or destructor.
+Otherwise, flowing off the end of the *compound-statement* of a
+*handler* of a *function-try-block* is equivalent to flowing off the end
+of the *compound-statement* of that function (see [[stmt.return]]).
+The variable declared by the *exception-declaration*, of type cv `T` or
+cv `T&`, is initialized from the exception object, of type `E`, as
 follows:
 - if `T` is a base class of `E`, the variable is copy-initialized (
   [[dcl.init]]) from the corresponding base class subobject of the
   exception object;
 object, any changes to the referenced object are changes to the
 exception object and will have effect should that object be rethrown.
 ## Exception specifications <a id="except.spec">[[except.spec]]</a>
+The predicate indicating whether a function cannot exit via an exception
+is called the *exception specification* of the function. If the
+predicate is false, the function has a *potentially-throwing exception
+specification*, otherwise it has a *non-throwing exception
+specification*. The exception specification is either defined
+implicitly, or defined explicitly by using a *noexcept-specifier* as a
+suffix of a function declarator ([[dcl.fct]]).
 ``` bnf
+noexcept-specifier:
     'noexcept' '(' constant-expression ')'
     'noexcept'
+    'throw' '(' ')'
 ```
+In a *noexcept-specifier*, the *constant-expression*, if supplied, shall
+be a contextually converted constant expression of type `bool` (
+[[expr.const]]); that constant expression is the exception specification
+of the function type in which the *noexcept-specifier* appears. A `(`
+token that follows `noexcept` is part of the *noexcept-specifier* and
+does not commence an initializer ([[dcl.init]]). The
+*noexcept-specifier* `noexcept` without a *constant-expression* is
+equivalent to the *noexcept-specifier* `noexcept(true)`. The
+*noexcept-specifier* `throw()` is deprecated ([[depr.except.spec]]),
+and equivalent to the *noexcept-specifier* `noexcept(true)`.
+If a declaration of a function does not have a *noexcept-specifier*, the
+declaration has a potentially throwing exception specification unless it
+is a destructor or a deallocation function or is defaulted on its first
+declaration, in which cases the exception specfication is as specified
+below and no other declaration for that function shall have a
+*noexcept-specifier*. In an explicit instantiation ([[temp.explicit]])
+a *noexcept-specifier* may be specified, but is not required. If a
+*noexcept-specifier* is specified in an explicit instantiation
+directive, the exception specification shall be the same as the
+exception specification of all other declarations of that function. A
+diagnostic is required only if the exception specifications are not the
+same within a single translation unit.
+If a virtual function has a non-throwing exception specification, all
 declarations, including the definition, of any function that overrides
+that virtual function in any derived class shall have a non-throwing
+exception specification, unless the overriding function is defined as
+deleted.
+[*Example 1*:
 ``` cpp
 struct B {
+  virtual void f() noexcept;
   virtual void g();
+  virtual void h() noexcept = delete;
 };
 struct D: B {
   void f();                     // ill-formed
+  void g() noexcept; // OK
+  void h() = delete;            // OK
 };
 ```
+The declaration of `D::f` is ill-formed because it has a
+potentially-throwing exception specification, whereas `B::f` has a
+non-throwing exception specification.
+— *end example*]
 Whenever an exception is thrown and the search for a handler (
+[[except.handle]]) encounters the outermost block of a function with a
+non-throwing exception specification, the function `std::terminate()` is
+called ([[except.terminate]]).
+[*Note 1*: An implementation shall not reject an expression merely
+because, when executed, it throws or might throw an exception from a
+function with a non-throwing exception specification. — *end note*]
+[*Example 2*:
 ``` cpp
+extern void f();                // potentially-throwing
+void g() noexcept {
+ f();                          // valid, even if f throws
+  throw 42; // valid, effectively a call to std::terminate
 }
 ```
+The call to `f` is well-formed even though, when called, `f` might throw
+an exception.
+— *end example*]
+An expression `e` is *potentially-throwing* if
+- `e` is a function call ([[expr.call]]) whose *postfix-expression* has
+  a function type, or a pointer-to-function type, with a
+  potentially-throwing exception specification, or
+- `e` implicitly invokes a function (such as an overloaded operator, an
+  allocation function in a *new-expression*, a constructor for a
+  function argument, or a destructor if `e` is a full-expression (
+  [[intro.execution]])) that is potentially-throwing, or
+- `e` is a *throw-expression* ([[expr.throw]]), or
+- `e` is a `dynamic_cast` expression that casts to a reference type and
+  requires a runtime check ([[expr.dynamic.cast]]), or
+- `e` is a `typeid` expression applied to a (possibly parenthesized)
+  built-in unary `*` operator applied to a pointer to a polymorphic
+  class type ([[expr.typeid]]), or
+- any of the immediate subexpressions ([[intro.execution]]) of `e` is
+  potentially-throwing.
+An implicitly-declared constructor for a class `X`, or a constructor
+without a *noexcept-specifier* that is defaulted on its first
+declaration, has a potentially-throwing exception specification if and
+only if any of the following constructs is potentially-throwing:
+- a constructor selected by overload resolution in the implicit
+  definition of the constructor for class `X` to initialize a
+  potentially constructed subobject, or
+- a subexpression of such an initialization, such as a default argument
+  expression, or,
+- for a default constructor, a default member initializer.
+[*Note 2*: Even though destructors for fully-constructed subobjects are
+invoked when an exception is thrown during the execution of a
+constructor ([[except.ctor]]), their exception specifications do not
+contribute to the exception specification of the constructor, because an
+exception thrown from such a destructor would call `std::terminate`
+rather than escape the constructor ([[except.throw]],
+[[except.terminate]]). — *end note*]
+The exception specification for an implicitly-declared destructor, or a
+destructor without a *noexcept-specifier*, is potentially-throwing if
+and only if any of the destructors for any of its potentially
+constructed subojects is potentially throwing.
+The exception specification for an implicitly-declared assignment
+operator, or an assignment-operator without a *noexcept-specifier* that
+is defaulted on its first declaration, is potentially-throwing if and
+only if the invocation of any assignment operator in the implicit
+definition is potentially-throwing.
+A deallocation function ([[basic.stc.dynamic.deallocation]]) with no
+explicit *noexcept-specifier* has a non-throwing exception
+specification.
+[*Example 3*:
 ``` cpp
 struct A {
+  A(int = (A(5), 0)) noexcept;
+  A(const A&) noexcept;
+  A(A&&) noexcept;
+  ~A();
 };
 struct B {
   B() throw();
+  B(const B&) = default; // implicit exception specification is noexcept(true)
+  B(B&&, int = (throw Y(), 0)) noexcept;
+  ~B() noexcept(false);
 };
+int n = 7;
 struct D : public A, public B {
+ int * p = new int[n];
+    // D::D() potentially-throwing, as the new operator may throw bad_alloc or bad_array_new_length
+    // D::D(const D&) non-throwing
+    // D::D(D&&) potentially-throwing, as the default argument for B's constructor may throw
+    // D::~D() potentially-throwing
 };
 ```
+Furthermore, if `A::~A()` were virtual, the program would be ill-formed
+since a function that overrides a virtual function from a base class
+shall not have a potentially-throwing exception specification if the
+base class function has a non-throwing exception specification.
+— *end example*]
+An exception specification is considered to be *needed* when:
 - in an expression, the function is the unique lookup result or the
   selected member of a set of overloaded functions ([[basic.lookup]],
   [[over.match]], [[over.over]]);
 - the function is odr-used ([[basic.def.odr]]) or, if it appears in an
   unevaluated operand, would be odr-used if the expression were
   potentially-evaluated;
+- the exception specification is compared to that of another declaration
+  (e.g., an explicit specialization or an overriding virtual function);
 - the function is defined; or
+- the exception specification is needed for a defaulted special member
+  function that calls the function. \[*Note 3*: A defaulted declaration
+ does not require the exception specification of a base member function
+ to be evaluated until the implicit exception specification of the
+ derived function is needed, but an explicit *noexcept-specifier* needs
+  the implicit exception specification to compare
+  against. — *end note*]
+The exception specification of a defaulted special member function is
 evaluated as described above only when needed; similarly, the
+*noexcept-specifier* of a specialization of a function template or
 member function of a class template is instantiated only when needed.
 ## Special functions <a id="except.special">[[except.special]]</a>
+The function `std::terminate()` ([[except.terminate]]) is used by the
+exception handling mechanism for coping with errors related to the
+exception handling mechanism itself. The function
+`std::current_exception()` ([[propagation]]) and the class
+`std::nested_exception` ([[except.nested]]) can be used by a program to
+capture the currently handled exception.
 ### The `std::terminate()` function <a id="except.terminate">[[except.terminate]]</a>
 In some situations exception handling must be abandoned for less subtle
+error handling techniques.
+[*Note 1*:
+These situations are:
 - when the exception handling mechanism, after completing the
   initialization of the exception object but before activation of a
   handler for the exception ([[except.throw]]), calls a function that
   exits via an exception, or
 - when the exception handling mechanism cannot find a handler for a
   thrown exception ([[except.handle]]), or
 - when the search for a handler ([[except.handle]]) encounters the
+  outermost block of a function with a non-throwing exception
+ specification ([[except.spec]]), or
 - when the destruction of an object during stack unwinding (
   [[except.ctor]]) terminates by throwing an exception, or
 - when initialization of a non-local variable with static or thread
+  storage duration ([[basic.start.dynamic]]) exits via an exception, or
 - when destruction of an object with static or thread storage duration
   exits via an exception ([[basic.start.term]]), or
 - when execution of a function registered with `std::atexit` or
   `std::at_quick_exit` exits via an exception ([[support.start.term]]),
   or
+- when a *throw-expression* ([[expr.throw]]) with no operand attempts
+ to rethrow an exception and no exception is being handled (
+  [[except.throw]]), or
 - when the function `std::nested_exception::rethrow_nested` is called
   for an object that has captured no exception ([[except.nested]]), or
 - when execution of the initial function of a thread exits via an
   exception ([[thread.thread.constr]]), or
+- for a parallel algorithm whose `ExecutionPolicy` specifies such
+  behavior ([[execpol.seq]], [[execpol.par]], [[execpol.parunseq]]),
+  when execution of an element access function (
+  [[algorithms.parallel.defns]]) of the parallel algorithm exits via an
+  exception ([[algorithms.parallel.exceptions]]), or
 - when the destructor or the copy assignment operator is invoked on an
   object of type `std::thread` that refers to a joinable thread (
+  [[thread.thread.destr]],  [[thread.thread.assign]]), or
+- when a call to a `wait()`, `wait_until()`, or `wait_for()` function on
+  a condition variable ([[thread.condition.condvar]],
+  [[thread.condition.condvarany]]) fails to meet a postcondition.
+— *end note*]
 In such cases, `std::terminate()` is called ([[exception.terminate]]).
 In the situation where no matching handler is found, it is
 *implementation-defined* whether or not the stack is unwound before
 `std::terminate()` is called. In the situation where the search for a
 handler ([[except.handle]]) encounters the outermost block of a
+function with a non-throwing exception specification ([[except.spec]]),
+it is *implementation-defined* whether the stack is unwound, unwound
+partially, or not unwound at all before `std::terminate()` is called. In
+all other situations, the stack shall not be unwound before
+`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 `std::terminate()`.
+### The `std::uncaught_exceptions()` function <a id="except.uncaught">[[except.uncaught]]</a>
+An exception is considered uncaught after completing the initialization
+of the exception object ([[except.throw]]) until completing the
+activation of a handler for the exception ([[except.handle]]). This
+includes stack unwinding. If an exception is rethrown ([[expr.throw]],
+[[propagation]]), it is considered uncaught from the point of rethrow
+until the rethrown exception is caught. The function
+`std::uncaught_exceptions()` ([[uncaught.exceptions]]) returns the
+number of uncaught exceptions in the current thread.
 <!-- Link reference definitions -->
+[algorithms.parallel.defns]: algorithms.md#algorithms.parallel.defns
+[algorithms.parallel.exceptions]: algorithms.md#algorithms.parallel.exceptions
 [basic.def.odr]: basic.md#basic.def.odr
 [basic.lookup]: basic.md#basic.lookup
+[basic.start.dynamic]: basic.md#basic.start.dynamic
+[basic.start.main]: basic.md#basic.start.main
 [basic.start.term]: basic.md#basic.start.term
 [basic.stc.dynamic.allocation]: basic.md#basic.stc.dynamic.allocation
 [basic.stc.dynamic.deallocation]: basic.md#basic.stc.dynamic.deallocation
 [class.copy]: special.md#class.copy
 [class.dtor]: special.md#class.dtor
+[conv.fctptr]: conv.md#conv.fctptr
 [conv.ptr]: conv.md#conv.ptr
+[conv.qual]: conv.md#conv.qual
+[dcl.fct]: dcl.md#dcl.fct
 [dcl.init]: dcl.md#dcl.init
+[depr.except.spec]: future.md#depr.except.spec
 [except]: #except
 [except.ctor]: #except.ctor
 [except.handle]: #except.handle
 [except.nested]: language.md#except.nested
 [except.spec]: #except.spec
 [except.special]: #except.special
 [except.terminate]: #except.terminate
 [except.throw]: #except.throw
 [except.uncaught]: #except.uncaught
 [exception.terminate]: language.md#exception.terminate
+[execpol.par]: utilities.md#execpol.par
+[execpol.parunseq]: utilities.md#execpol.parunseq
+[execpol.seq]: utilities.md#execpol.seq
+[expr.call]: expr.md#expr.call
 [expr.const]: expr.md#expr.const
 [expr.dynamic.cast]: expr.md#expr.dynamic.cast
 [expr.new]: expr.md#expr.new
+[expr.throw]: expr.md#expr.throw
 [expr.typeid]: expr.md#expr.typeid
 [futures]: thread.md#futures
+[intro.execution]: intro.md#intro.execution
+[intro.races]: intro.md#intro.races
 [over.match]: over.md#over.match
 [over.over]: over.md#over.over
 [propagation]: language.md#propagation
+[stmt.jump]: stmt.md#stmt.jump
 [stmt.return]: stmt.md#stmt.return
 [stmt.stmt]: stmt.md#stmt.stmt
 [structure.specifications]: library.md#structure.specifications
 [support.start.term]: language.md#support.start.term
+[temp.explicit]: temp.md#temp.explicit
+[thread.condition.condvar]: thread.md#thread.condition.condvar
+[thread.condition.condvarany]: thread.md#thread.condition.condvarany
 [thread.thread.assign]: thread.md#thread.thread.assign
 [thread.thread.constr]: thread.md#thread.thread.constr
 [thread.thread.destr]: thread.md#thread.thread.destr
+[uncaught.exceptions]: language.md#uncaught.exceptions

Diff to HTML by rtfpessoa