P3166R0: Static Exception Specifications

4.1.1. Composition of facilities that use different error-signaling mechanisms

4.1.2. Runtime overhead due to additional branching, packing/unpacking

4.1.3. May require an additional "invalid" state, additional preconditions

4.5.1. Uses in generic code

5.3.1. Types in a throw-specification form an unordered set

void f() throw(E1, E2);
void g() throw(E2, E1);
void h() throw(E1, E1, E2);

// declared in lib1
void f() throw(E1, E2);

// declared in lib2
void g() throw(E2, E1);


void (*func)() throw(E1, E2) = &f;
if (cond) {
  func = &g; // It would be annoying if this was ill-formed because the throw-specification had a different order.
}

5.3.2. Handling of std::any_exception in the throw-specifier

void a() throw(std::any_exception);       // -> throw(...)
void b() throw(A, B, std::any_exception); // -> throw(...)

template<typename... Ts>
using ...pack = Ts; // P1858R2 pack alias syntax

// Generic case
template<typename T>
struct _compute_foo_throw_types {
  using ...types = pack<std::any_exception>; // P1858R2 pack alias syntax
};

// When T satisfies the Foo concept, we know it will only
// fail with two possible exceptions.
template<typename T>
  requires Foo<T>
struct _compute_foo_throw_types<T> {
  using ...types = pack<FooError, std::bad_alloc>;
};

template<typename T>
void foo(const T& x) throw(_compute_foo_throw_types<T>::...types...); // P1858R2 pack expansion syntax

5.3.3. The types in the throw specification describe all concrete types that may be thrown

5.3.4. Exception types may not be references, cv-qualified, or void

5.3.5. Static exception specifications are part of the function type

void f() throw();
void g() throw(E1);
void h() throw(E1, E2);
void i() throw(...);

void(*pf)() throw() = f; // OK
pf = g; // ERROR - can't cast g() to a function-ptr with narrower throw-specification
pf = h; // ERROR - can't cast h() to a function-ptr with narrower throw-specification
pf = i; // ERROR - can't cast i() to a function-ptr with narrower throw-specification

void(*pg)() throw(E1) = g; // OK
pg = f; // OK - points either to f or to thunk that calls f
pg = h; // ERROR - can't cast h() to a function-ptr with narrower throw-specification
pg = i; // ERROR - can't cast i() to a function-ptr with narrower throw-specification

void(*ph)() throw(E1, E2) = h; // OK
ph = f;  // OK - ph points to f or to a thunk that calls f
ph = g;  // OK - ph points to a thunk that calls g
ph = i;  // ERROR - can't cast i() to function-ptr with narrower throw-specification

void(*pi)() throw(...) = i; // OK
pi = f; // OK - ph points to f (same as casting noexcept(true) function-ptr to a noexcept(false) one)
pi = g; // OK - ph points to a thunk that calls g and translates static-exceptions into dynamic-exceptions
pi = h; // OK - ph points to a thunk that calls g and translates static-exceptions into dynamic-exceptions

// The same casts are not all valid when casting function-pointers to other function-pointer
// types instead of functions to function-pointer types.
pf = pg; // ERROR: Can't cast function-ptr with static throw specification to another function-ptr type
pf = ph; // ERROR: (same)
pf = pi; // ERROR: Can't cast throw(...) function-ptr to throw() function-ptr

pg = pf; // MAYBE?: In some ABIs the calling convention may be compatible.
         // Do we want to restrict the options here?
pg = ph; // ERROR: Can't cast to function-ptr with narrower throw-specification
pg = pi; // ERROR: Can't cast to function-ptr with narrower throw-specification

ph = pf; // MAYBE?: In some ABIs the calling convention may be compatible.
ph = pg; // ERROR: Can't cast function-ptr with static exception specification to function-ptr with a
         // different exception specification. Compiler is unable to generate the necessary thunk here.
ph = pi; // ERROR: Can't cast to function-ptr with narrower throw-specification.

pi = pf; // OK: this is same as casting function-ptr with noexcept(true) to function-ptr with noexcept(false)
pi = pg; // ERROR: Can't cast function-ptr with static exception specification to function-ptr with
         // different exception specification. Compiler is unable to generate the necessary thunk here.
pi = ph; // ERROR: Can't cast function-ptr with static exception specification to function-ptr with
         // different exception specification.

5.3.6. Deducing the throw-specifier from a function signature

template<typename Ret, typename... Args, typename... Errors>
void Call(Ret(*func_ptr)(Args...) throw(Errors...));

void a() throw();
void b() throw(int);
void c() throw(std::bad_alloc, std::system_error);
void d() throw(...);

Call(&a); // deduces Errors to be the empty pack.
Call(&b); // deduces Errors to be the pack: int
Call(&c); // deduces Errors to be the pack: std::bad_alloc, std::system_error   (in some unspecified order)
Call(&d); // deduces Errors to be the pack: std::any_exception

5.3.7. throw(auto) - Deducing exception-specifications from the body of a function

1. Prior work on deducing exception specifications
   

   This usability issue was identified as a problem back when noexcept was originally proposed for C++11:

   • N3227 - Please reconsider noexcept (Ottosen, 2010)

   There have since been multiple papers exploring the idea of deducing the exception-specification:

   • N3202 - To which extent can noexcept be deduced? (Stroustrup, 2010)
   • N3207 - noexcept(auto) (Merrill, 2010)
   • N4473 - noexcept(auto), again (Voutilainen, 2015)
   • P0133R0 - Putting noexcept(auto) on hold, again (Voutilainen, 2015)

   It is worth noting that the rationale given in P0133R0 for putting on hold the pursuit of noexcept(auto) was mainly because it did not solve the whole problem of having to duplicate the function-body in the declaration - the expressions of the body still needed to be duplicated in the return-type for SFINAE purposes - and therefore it was not good use of committee time to pursue a partial solution.

   Since this paper was written, we have gained support for concepts in C++20, which goes some way to simplifying the code needed to write function-templates that eliminates overloads with SFINAE. However, this only applies when there are existing concepts defined that can be used to constrain the function. For many cases you still need to duplicate the expressions of the function body in a requires clause.

   Despite this limitation, I feel there is still benefit to enabling deduced exception specifications as there are often case that are either covered by concepts or that do not require SFINAE, but that do need to compute accurate exception specifications.

2. throw(auto)
   

   With the (re)introduction of throw-specifiers, the task of computing a correct throw-specification from a set of sub-expressions becomes even more onerous than for noexcept, as you need to compute lists of types, not just a boolean expression.

   This paper therefore proposes the addition of the throw(auto) specifier on a function declaration, as a way of declaring that the compiler should compute the set of exception types that may exit the function from the definition of the body of the function and use that as the exception-specification for the function.

   For example, consider a hypothetical for_each function that invokes a function for each element of a range. If we wanted this function to have the same exception-specification as its body, it would need to be written with noexcept specifiers, something similar to the following:

   template<
     std::ranges::range Range,
     typename Func>
   requires std::invocable<Func&, std::ranges::range_reference_t<Range>>
   void for_each(Range&& range, Func&& func)
     noexcept(noexcept(std::ranges::begin(range)) &&
              noexcept(std::ranges::end(range)) &&
              noexcept(++std::declval<std::ranges::iterator_t<Range>&>()) &&
              noexcept(std::declval<std::ranges::iterator_t<Range>&>() != std::declval<std::ranges::sentinel_t<Range>&>()) &&
              noexcept(func(*std::declval<std::ranges::iterator_t<Range>&>()))) {
     auto iterEnd = std::ranges::end(range);
     auto iter = std::ranges::begin(range);
     while (iter != iterEnd) {
       func(*iter);
       ++iter;
     }
   }
   

   And with the throw() specifier proposed by this paper, in conjunction with the declthrow() expression (described in detail in the following section), we would need to write:

   template<std::ranges::range Range, typename Func>
   requires std::invocable<Func&, std::ranges::range_reference_t<Range>>
   void for_each(Range&& range, Func&& func)
     throw(declthrow(std::ranges::begin(range))...,
           declthrow(std::ranges::end(range))...,
           declthrow(++std::declval<std::ranges::iterator_t<Range>&>())...,
           declthrow(std::declval<std::ranges::iterator_t<Range>&>() != std::declval<std::ranges::sentinel_t<Range>&>())...
           declthrow(func(*std::declval<std::ranges::iterator_t<Range>&>()))...)  {
     auto iterEnd = std::ranges::end(range);
     auto iter = std::ranges::begin(range);
     while (iter != iterEnd) {
       func(*iter);
       ++iter;
     }
   }
   

   Having to repeat the body in a different way in the noexcept or throw specification like this is tedious and error-prone. It can be easy to miss an expression, or to later modify the body of the function and forget to update the throw-specification.

   Instead, if we use the proposed throw(auto) syntax, then the function definition simply becomes:

   template<std::ranges::range Range, typename Func>
   requires std::invocable<Func&, std::ranges::range_reference_t<Range>>
   void for_each(Range&& range, Func&& func) throw(auto) {
     auto iterEnd = std::ranges::end(range);
     auto iter = std::ranges::begin(range);
     while (iter != iterEnd) {
       func(*iter);
       ++iter;
     }
   }
   

   This is much more concise, and is now impossible for the throw-specification to be inconsistent with the function body.

   This facility will greatly simplify the definition of function-templates, in particular the function-templates that are defined as "expression-equivalent to" some expression or statement sequence.

3. Further motivation for throw(auto) from P2300 std::execution
   

   One place where having accurate exception specifications (whether noexcept or throw() specifications) is when using the std::execution facility proposed in P2300.

   There are generic async algorithms that can potentially have more efficient implementations if they know that a given operation cannot fail with an error.

   For example when_all() when passed a collection of senders that cannot complete with an error the implementation can avoid introducing expensive stop-token synchronization required for cancelling other child operations if one of them fails. It can also avoid having to reserve storage for a std::exception_ptr (or other error type) in the operation-state in order to be able to stash the error while waiting for the other operations to stop.

   So throughout the design of P2300, the specification tries to ensure that, as much as possible, the noexcept-ness of expressions are passed-through. An unnecessarily conservative noexcept(false) can result in additional overhead that the compiler cannot inline away like it can for normal functions.

   The noexcept-ness of operations on arguments passed to std::execution algorithms can influence the return-type of functions, whether particular overloads of template set_error() functions are instantiated, etc. and so can influence the ABI and whether a program is well-formed.

   For users using the std::execution algorithms, using the throw(auto) syntax would be beneficial for cases where they are passing lambdas as parameters to these algorithms and they either:

   1. Don't care whether or not the expressions could throw, but if they can then just do the right thing by having those expressions transparently propagate exceptions, and if they don't then do the fast thing.
   2. The do care, but they are writing generic code which may or may not be noexcept depending on the types it is instantiated with.

   For example:

   template<std::execution::sender S>
   auto sender_example(S source) throw(auto) {
     return std::move(source)
       | std::execution::then([](const auto& data) throw(auto) {
           // do something with data that might throw or might not throw depending on 'data'
           return some_computed_value;
         })
       | std::execution::let_value([](auto& computed_value) throw(auto) {
           return std::execution::when_all(
             sub_operation_1(computed_value),
             sub_operation_2(computed_value))
           | std::execution::then([&](auto op_1_result, auto op_2_result) throw(auto) {
               // ... combine results
               return some_expr;
             });
         });
   }
   

   If we want this expression to produce a sender that is no-fail when the lambdas within it are guaranteed not to throw exceptions then currently you'd have to duplicate the body of each of the lambdas in the noexcept/throw-specifier. This greatly affects the readability of this sort of code. Most people are probably not going to bother and so the sender algorithm will have to pessimistically choose a less-efficient implementation to handle the possibility that some of those expressions might throw. If the author of the lambdas had access to throw(auto) then users would probably annotate their lambdas as a matter of course so that their sender/receiver code runs faster when appropriate.

5.3.8. Forward declarations of throw(auto) functions

void example() throw(auto);

void caller1() {
  example();  // ill-formed. cannot be ODR-used before the definition is seen
}

auto* example_ptr = &example; // ill-formed. Type of example() is not known until definition is seen.

void caller2() throw(declthrow(example())...); // ill-formed. Cannot query the exception specification
                                               // of example() before it's definition is seen.
void caller3() noexcept(noexcept(example())); // ill-formed. For same reason.

void example() throw(auto) {
  if (foo()) {
    do_thing1();
  } else {
    try {
      do_thing2();
    } catch (Thing2Failure) {
      do_backup_thing2();
    }
  }
}

// Now that the definition is visible and the exception-specification
// can be deduced, the following usages are well-formed.

void caller4() throw(declthrow(example())...) { // OK
  example(); // OK
}

auto* example_ptr2 = &example; // OK

5.3.9. Deduced exception-specifications and recursive functions

struct Tree {
  Tree* left;
  Tree* right;
  int value;
};

void process_value(int value) throw(InvalidValue);

void process_tree(Tree& tree) throw(auto) {
  if (tree.left != nullptr)
    process_tree(*tree.left);

  process_value(tree.value); // recursive-call

  if (tree.right != nullptr)
    process_tree(*tree.right);
}

void contradiction(int arg) throw(auto) {
  if constexpr (noexcept(contradiction(arg)) {
    throw X{};
  } else {
    if (arg > 0)
      return contradiction(arg - 1);
  }
}

5.3.10. Delayed computation of deduced throw specifications

5.3.11. Do we also need noexcept(auto)?

void a() throw(A);
void b() throw(B);

void c() throw(auto) { // deduces to throw(A, B)
  a();
  b();
}

void d() noexcept(auto) { // deduces to noexcept(false)
  a();
  b();
}

void execute(void(*func)());

void example() {
  auto* c_ptr = &c;
  execute(c_ptr); // ill-formed: no conversion from 'void(*)() throw(A,B)' to 'void(*)()'

  auto* d_ptr = &d;
  execute(d_ptr); // OK: 'void(*)() noexcept' implicitly convertible to 'void(*)()'.
}

void workaround() {
  execute(static_cast<void(*)()>(c)); // OK: explicit cast to noexcept(false) function-pointer from function
  execute(&d); // OK: Explicit cast not needed
}

5.4.1. declthrow of a call to a throw(...) function

namespace std {
  // NOTE: using pack indexing syntax proposed in P2662R2
  using any_exception = declthrow(static_cast<void(*)()throw(...)>(nullptr)())...[0];
}

5.4.2. Mixed dynamic and static exception specifications

// Given the following
struct X;
struct Y;
int foo() throw(X, Y);
void bar(int x) throw(...);

// What types are in the following type-list?
using types = type_list<declthrow(bar(foo()))...>;

template<typename T, typename... Ts>
concept one_of = (std::same_as<T, Ts> || ...);

template<typename... Es>
using err_variant = std::variant<std::monostate,
                                 std::conditional_t<std::same_as<std::any_exception, Es>,
                                                    std::exception_ptr, Es>...>;

err_variant<declthrow(do_foo())...> error;
try {
  do_foo();
} template catch (auto e) {
  error.emplace<decltype(e)>(std::move(e));
} catch (...) {
  if constexpr (one_of<std::any_exception, declthrow(do_foo())...>) {
    error.emplace<std::exception_ptr>(std::current_exception());
  }
}

5.4.3. Order of the exception types

5.4.4. Exception specifications of defaulted special member functions

struct A {
  A() throw(std::bad_alloc);
  A(const A&) throw(std::bad_alloc);
  A(A&&) throw();
  ~A();
};

struct B {
  B() throw(std::system_error);
  B(const B&) throw(std::system_error);
  B(B&&) throw();
  ~B();
};

struct C {
  A a;
  B b;

  // C has implicitly defaulted special member functions.
};

template<typename... Ts>
struct type_list;

template<typename Func>
struct throw_specification;

template<typename Ret, typename... Args, typename... Es>
struct throw_specification<Ret(Args...) throw(Es...)> {
  using types = type_list<Es...>;
};

// Sorts the list of types in the canonical order for a throw-specification
template<typename... Ts>
using throw_specification_t = typename throw_specification<void() throw(Ts...)>::types;

// The following static_asserts will always pass for conforming implementations.

static_assert(std::same_as<throw_specification_t<declthrow(C{})...>,
                           throw_specification_t<std::bad_alloc, std::system_error>>);
static_assert(std::same_as<throw_specification_t<declthrow(C{std::declval<const C&>()})...>,
                           throw_specification_t<std::bad_alloc, std::system_error>>);
static_assert(std::is_nothrow_move_constructible_v<C>);

// Ideally the following would hold true for all implementations.
// i.e. the throw-specification of the default constructor of std::tuple is the union
// of the throw-specifications for all of the tuple member default constructors.
static_assert(std::same_as<throw_specification_t<declthrow(std::tuple<A, B>{})...>,
                           throw_specification_t<std::bad_alloc, std::system_error>>);

5.4.5. Introducing a pack outside of a template

template<typename... Ts> class type_list {};

// Can pass the result as template arguments to a class-template.
using error_types = type_list<declthrow(foo(a,b,c))...>;

template<typename T, typename... Ts>
concept one_of = (std::same_as<T, Ts> || ...);

// Can pass the result as template-arguments to a concept.
constexpr bool throws_bad_alloc =
   one_of<std::bad_alloc, declthrow(foo(a,b,c))...>;

// Can use it to compute the type of a variant that can hold all
// possible exception types that might be thrown.
std::variant<std::monostate, declthrow(foo(a,b,c))...> error;
try {
    foo(a,b,c);
} template catch (auto e) {
  error.template emplace<decltype(e)>(std::move(e));
}

// Can use it in the throw-specification of a function that wants to transparently
// throw whatever exceptions foo() throws, plus errors that it throws itself.
void example(int a, int b, int c) throw(std::system_error, declthrow(foo(a,b,c))...);

void foo() throw(A, B);

template<typename Nested>
struct BarError {
  Nested nested;
};

void bar(int count) throw(BarError<declthrow(foo())>...) {
  try {
    for (int i = 0; i < count; ++i) {
      foo();
    }
  } template catch(auto e) {
    throw BarError<decltype(e)>{std::move(e)};
  }
}

template<typename... Ts>
struct compute_new_exception_types {
  using type = type_list< /* template magic goes here */>;
};

template<typename T>
void algorithm(const T& obj)
   throw(typename compute_new_exception_types<
           declthrow((obj.foo(), obj.bar()))...>::type /* how to expand this to a pack here? */);

5.4.6. Packs of declthrow packs

template<typename T, typename Func>
    requires std::invocable<Func&, T&>
void for_each(std::span<T> values, Func&& func) throw(declthrow(func(std::declval<T&>()))...);

template<typename... Ts, typename Func>
    requires (std::invocable<Func&, Ts&> && ...)
void for_each(std::tuple<Ts...>& values, Func&& func) throw(declthrow(func(std::declval<Ts&>()))... ...);

template<typename... Ts, typename Func>
    requires (std::invocable<Func&, Ts&> && ...)
void for_each(std::tuple<Ts...>& values, Func&& func) throw(declthrow((func(std::declval<Ts&>()), ...))...);

5.4.7. Availability of the declthrow keyword

5.4.8. Alternative Syntaxes Considered

5.4.9. Filtering the set of exceptions

template<typename ErrorType>
[[noreturn]] _throws() throw(ErrorType);

template<typename HandledType, typename ErrorType>
void _handle() throw(auto) {
  if constexpr (not std::same_as<HandledType, std::any_exception>) {
    try { _throws<ErrorType>(); } catch(HandledType) {}
  }
}

// P3115R0 pack alias syntax
template<typename HandledType, typename... Errors>
using ...filter_exceptions = declthrow((_handle<HandledType, Errors>(), ...));

void example() throw(filter_exceptions<CaughtException, declthrow(some_expression)...>...);

// Given.
struct A : std::exception {};
struct FooError : std::exception {};
struct B : FooError {};
struct C : FooError {};

void foo() throw(A, B, C);

void example1() throw(declthrow(foo())...);                        // -> throw(A, B, C)
void example2() throw(declthrow(foo(), catch(A))...);              // -> throw(B, C)
void example3() throw(declthrow(foo(), catch(A), catch(B))...);    // -> throw(C)
void example4() throw(declthrow(foo(), catch(FooError))...);       // -> throw(A)
void example5() throw(declthrow(foo(), catch(std::exception))...); // -> throw()

5.6.1. Statement Reachability

1. Interrupted-flow statements
   

   An interrupted-flow statement is a statement for which execution cannot flow to the next statement from this statement.

   The following statements are interrupted-flow statements:

   • A jump-statement - i.e. break;, continue;, goto;, return expr-or-braced-init-list[opt]; or coroutine-return-statement.
   • A compound-statement where execution cannot flow off the end of the block (see below)
   • An if or if-else selection-statement where either;
     • the init-statement, if any, is an interrupted-flow statement; or
     • the condition is an interrupted-flow expression.
   • An if-else selection-statement where the first and second sub-statements are both interrupted-flow statements. Note: this includes if consteval selection-statements.
   • A constexpr if or if-else selection-statement where the condition evaluated to true and the first sub-statement is an interrupted-flow statement.
   • A constexpr if-else selection-statement where the condition evaluated to false and the second sub-statement is an interupted-flow statement.
   • A try-block where the compound-statement is an interrupted-flow statement and the compound-statement of every reachable handler (see section on try-block below) of the try-block's handler-seq is an interrupted-flow statement.
   • A switch selection-statement where either;
     • the init-statement, if any, is an interrupted-flow statement; or
     • the condition is an interrupted-flow expression; or
     • all of the following are true;
       • the body statement is an interrupted-flow statement; and
       • the body statement has a default: label associated with the switch; and
       • there is no potentially-reachable break; statement associated with the switch.
   • A do-while iteration-statement where both the following are true;
     • the loop body statement does not enclose any potentially-reachable break; statements associated with the loop; and
     • either;
       • both of the following are true;
         • the loop body statement does not enclose any potentially-reachable continue; statements associated with the loop; and
         • the loop body statement is an interrupted-flow statement; or
       • the loop expression is an interrupted-flow expression
   • A for or while iteration-statement where either;
     • the init-statement, if present, is an interrupted-flow-statement; or
     • the condition expression is an interrupted-flow expression;
   • A range-based for iteration-statement where either;
     • the init-statement is an interrupted-flow statement; or
     • the for-range-initializer expression is an interrupted-flow expression; or
     • the begin-expr is an interrupted-flow expression; or
     • the end-expr is an interrupted-flow expression.
   • An expression-statement where the expression is an interrupted-flow expression.
   • A declaration-statement that is an object declaration where the initializer expression is an interrupted-flow expression.
2. Interrupted-flow expressions
   

   An interrupted-flow-expression is a potentially evaluated expression that is one of the following:

   • A throw-expression
   • A postfix-expression that evaluates a call to a function marked [[noreturn]].
   • A conditional-expression (ternary ?: operator) where either;
     • the first sub-expression is an interrupted-flow-expression; or
     • the second and third sub-expressions are both interrupted-flow-expressions.
   • A built-in logical AND or logical OR expression where the first sub-expression is an interrupted-flow expression.
   • A prvalue expression of class type whose destructor is marked [[noreturn]].
   • Any other compound expression that has an immediate sub-expression that is an interrupted-flow-expression.
3. Potentially-reachable statements
   

   A potentially-reachable statement is a statement of a function that the compiler determines can potentially be executed based on a local analysis of the control-flow of the function. It does not consider the values of any expressions which are semantically computed at runtime.

   1. Reachability of compound-statements
      

      A sub-statement of a compound-statement is a potentially-reachable statement if:

      • it is the first sub-statement of the compound-statement and the compound-statement is reachable; or
      • the immediately preceding statement is a potentially-reachable statement and was not an interrupted-flow-statement; or
      • the statement was immediately preceded by a label (Note: this does not include the implicit labels mentioned in the definition of a while statement)

      Otherwise a sub-statement of a compound-statement is considered an unreachable-statement.

      A compound-statement that is the top-level compound-statement of a function body or lambda body is a potentially reachable statement.

   2. Reachability of components of an if-statement
      

      In an if-statement of the form if ( /condition/ ) /statement/ or if ( /init-statement/ /condition/ ) /statement/ with or without the else /statement/ then;

      • The init-statement, if present, is a potentially-reachable statement if the if-statement is a potentially-reachable statement.
      • The condition expression is a potentially reachable statement if;
        • The if-statement is potentially reachable; and
        • The init-statement is either not present, or if present, is not an interrupted-flow statement.
      • The first and second (if present) statement is a potentially reachable statement if the condition expression is a potentially-reachable expression and the condition expression is not an interrupted-flow expression.

      In a constexpr if statement;

      • the first substatement is potentially reachable if and only if the if-statement is potentially reachable and the condition evaluates to true;
      • the second substatement, if present, is potentially reachable if and only if the if-statement is potentially reachable and the condition evaluates to false.
   3. Reachability of components of a switch statement
      

      In a switch-statement of the form switch ( /condition/ ) /statement/:

      • the condition expression is potentially reachable if the switch-statement is potentially reachable

      And, in a switch-statement of the form switch ( /init-statement/ /condition/ ) /statement/:

      • the init-statement is potentially reachable if the switch-statement is potentially reachable
      • the condition expression is potentially reachable if the switch-statement is potentially reachable; and the init-statement was not an interrupted-flow statement.

      In both cases, the statement is not potentially-reachable. Execution can only enter statement via a jump to a label enclosed by statement.

      Any case and default labels associated with the switch statement are potentially reachable if and only if the condition expression is potentially reachable and is not an interrupted-flow expression.

      For example:

      void f(int x) {
        switch (x) {
          a; // not-reachable
        case 0:
          b; // reachable - appears after a label
          break;
          c; // not reachable - appears after a jump-statement
        default:
          d; // reachable - appears after a label
        }
      }
      

   4. Reachability of components of an iteration-statement
      

      In an iteration-statement of the form while ( /condition/ ) /statement/

      • The condition is a potentially reachable expression if the while-statement is a potentially reachable statement
      • The statement is a potentially reachable statement if the condition expression is potentially reachable and the condition expression is not a flow-interrupted expression.

      In an iteration-statement of the form do /statement/ while ( /expression/ ) ;

      • The statement is potentially reachable statement if the do-statement is potentially reachable
      • The expression is a potentially reachable expression if do-statement is potentially reachable and either;
        • the statement is not a flow-interrupted statement; or
        • the statement encloses a potentially reachable continue; statement associated with the do-statement

      In an iteration-statement of the form for ( /init-statement/ /condition/ ; /expression/ ) /statement/

      • The init-statement is potentially-reachable if the for-statement is potentially-reachable
      • The condition expression (if present) is potentially-reachable if the for-statement is potentially-reachable and the init-statement is not an interrupted-flow statement
      • The statement is a potentially-reachable statement if the init-statement is a potentially-reachable statement and is not an interrupted-flow statement and either the condition expression is not present or the condition expression is not an interrupted-flow expression.
      • The expression is a potentially-reachable expression if either;
        • The statement is a potentially-reachable statement and is not an interrupted-flow statement; or
        • There is a potentially-reachable continue; statement enclosed by statement that is associated with the for-loop.
   5. Reachability of identifier labels
      

      These rules treat all identifier labels as potentially-reachable and does not do any analysis to determine whether there is any jump-statement that could potentially jump to that label.

      For example, the rules could potentially require looking elsewhere in the function to determine whether there are any goto statements that target a particular label.

      However, requiring this prevents doing analysis of reachability in a single pass as you may need to look later in the function in order find a goto statement that targets a label earlier in the function.

      For example: When the compiler reaches the retry: label it has not yet seen the goto retry; statement and so does not yet know whether retry: label is reachable.

      int foo(int x) {
        {
          auto result = try_fast(x);
          if (!result) {
            goto slow;
          }
      
          return result.value();
        }
      
       retry:
        reset_slow();
      
       slow:
        auto result = try_slow(x);
        if (!result) {
          goto retry;   // only know that 'retry:' label is reachable after processing this statement
        }
      
        return result.value();
      }
      

      An even more sophisticated approach could consider the potential reachability of the goto statement targeting a label itself.

      There may be cycles of reachability of goto statements which are not themselves reachable from the function entry-point.

      For example: In the following function there is a goto statement targeting each of the labels in this function, but none of those goto statements are themselves reachable from the function entry-point.

      void foo(int x) {
        if constexpr (false) {
          goto foo;
        }
      
        return x;
      
       foo:
        if (x < 0)
          throw negative_error{};
        goto baz;
      
       bar:
        --x;
        goto foo;
      
       baz:
        goto bar;
      }
      

      It is not difficult to imagine such code occuring in practice in function templates where there are goto statements in if constexpr branches that are either discarded or not discarded, depending on the types the function template was instantiated with.

      The rules could potentially be extended to consider a label as potentially reachable only if there is a potentially reachable goto statement that targets the label.

      Computing the reachability in this case would basically require the compiler to hold the control-flow graph of the entire function in memory and then walk that graph, marking statements as reachable or not. This may be incompatible with the architecture of some compiler implementations.

      The proposed design chooses a more conservative algorithm that treats all labels as reachable in order to permit implementations that can compute a more conservative concept of reachability in a single pass.

      It is not clear whether or not handling such cases in a more accurate way would be worth the additional complexity it would place on implementations.

4. Flowing off the end of a compound-statement
   

   Execution may flow off the end of a compound-statement if either;

   • the compound-statement is a potentially-reachable statement and has an empty sequence of sub-statements; or
   • both;
     • the last sub-statement of the compound-statement is potentially-reachable and is not an interrupted-flow-statement (Note: This includes any null sub-statement implicitly inserted after a trailing label immediately before the closing brace); and
     • There are no object declarations declared in the scope of the compound-statement that have destructors that have the attribute [[noreturn]].
5. Flowing off the end of a switch statement
   

   The rules for determining that a switch statement is an interrupted-flow statement require that the body of the switch statement has a default: label associated with the switch.

   This approach is somewhat conservative, as it may be possible that all of the potential cases are already covered by case labels and that, therefore, it is not possible for the switch statement to jump over the statement body and flow onto the next statement.

   For example: The rules above result in the following

   void example(bool x) {
     // Not an interrupted-flow statement - no default: case
     switch (x) {
     case true: throw X{};
     case false: throw Y{};
     }
     // The following statement is considered potentially-reachable.
   
     // An interrupted-flow statement - has a default: case
     switch (x) {
     case true: throw X{};
     default: throw Y{};
     }
   
     // Not potentially-reachable.
     // Prior statement is an interrupted-flow statement.
     // Control cannot flow off the end of the function's compound-statement.
   }
   

   The rationale here is that trying to determine whether every possible value for the switch expression is covered by a case label is non-trivial and/or probably doesn't do what you want.

   For example: Consider switching on an enum where all enum members have case labels.

   enum class state_t { stopped = 0, starting = 1, running = 2 };
   
   int example(state_t state) {
     switch (state) {
     case state_t::stopped: return 0;
     case state_t::starting: return 1;
     case state_t::running: return 2;
     }
   
     foo(); // should this statement be considered "potentially-reachable"?
   }
   
   // Consider the following call.
   example(static_cast<state_t>(3));
   

   If, instead, we just look for a default: label then we know that every possible case is handled.

   If we are willing to define rules for determining whether all possible cases are listed as case labels then we could potentially relax the rule requiring the use of a default: label here.

6. Use of [[noreturn]] for normative semantics
   

   The rules above treat calls to functions marked as [[noreturn]] as being interrupted-flow expressions and the interpretation as such can potentially affect the computation of the set of potentially-thrown exceptions, which in turn can affect the semantics and well-formedness of a program.

   The use of an attribute in this way is novel and would no longer have optional semantics, which would go against the intent of the following note in [dcl.attr.grammar] p6

   [Note : The attributes specified in \[dcl.attr] have optional semantics: given a well-formed program, removing all instances of any one of those attributes results in a program whose set of possible executions (\[intro.abstract]) for a given input is a subset of those of the original program for the same input, absent implementation-defined guarantees with respect to that attribute. — end note]

   The statement reachability computation depends on the ability to determine whether a function can return normally and flow to the next statement or not. For example, programs may insert calls to std::terminate() or std::unreachable() before the end of a compound-statement to indicate that control should not flow off the end (e.g. after a loop that is never expected to exit except by return).

   If we do not wish to give the [[noreturn]] attribute normative semantics, then perhaps we should explore defining an alternative normative mechanism for annotating functions as never returning normally.

5.6.2. function-body

5.6.3. statement

5.6.4. expression-statement

5.6.5. compound-statement

void foo() throw(A);
void bar() throw(B, C);
void baz() throw(D);

{
  foo(); // might throw A
  goto label;
  bar(); // might throw B or C (note this is an unreachable-statement)
label:
  baz(); // might throw D
}

5.6.6. selection-statement

1. if statements
   

   The set of potentially-thrown exception types of an if statement is the union of the potentially-thrown exception types of the:

   • init-statement - if present
   • condition expression
   • statement - the first substatement
   • statement - the second substatement (if the else part is present)

   Note that the computation of potentially-thrown exception types does not consider whether or not the condition is a constant expression or not - both branches of sub-statements are always considered when computing the set of potentially-thrown exception-types.

   For example: The following if-statement has a set of potentially-thrown exception types equal to { X }, despite the condition being a constant

   if (false) {
     throw X{};
   }
   

   If you want to force the branching decision to be performed at compile-time then use the if constexpr form of selection-statement (see below).

   1. Reachability of if-statement components
      

      With if-statements there is the question of whether we should consider the set of potentially-thrown exceptions of the first or second sub-statements if either the init-statement is a interrupted-flow statement, or if the condition is an interrupted-flow expression.

      For example: Should the following function, f() deduce to a throw-specification of throw(X) or to throw(X, Y, Z)?

      [[noreturn]] bool throws_something() throw(X);
      
      void f() throw(auto) {
        if (throws_something()) {
          throw Y{};
        } else {
          throw Z{};
        }
      }
      

      The rules above do not try to compute the individual reachability of the substatements and applying the rules as written would result in a deduced exception specification for f() of throw(X, Y, Z).

      While it would be relatively straight-forward to extend the rules to, instead, compute a deduced exception specification of throw(X), it is not clear that this would bring significant value, as this kind of code is expected to be relatively rare, and could be straight-forwardly rewritten in a form that separates the interrupted-flow expression into a separate statement.

      For example: The following code is equivalent but deduces the throw-specification to throw(X) according to the above rules since the if-statement is not a reachable statement.

      void f() throw(auto)  {
        bool cond = throws_something();
        // The if-statement is unreachable as prior statement was an interrupted-flow statement.
        if (cond) {
          throw Y{};
        }  else {
          throw Z{};
        }
      }
      

2. if constexpr statements
   

   As the condition of a constexpr if statement is evaluated as part of constant evaluation and a constant evaluation is not permitted to result in a thrown exception, the condition part does not contribute to the set of potentially-thrown exception types.

   If the selection-statement contains an init-statement part, then let I be the set of potentially-thrown exception types of the init-statement, otherwise let I be the empty set.

   If the value of the converted condition expression is true then then set of potentially-thrown exception types of the selection-statement is the union of I and the set of potentially-thrown exception types of the the first substatement. i.e. the body of the if statement.

   Otherwise, if the else part of the selection statement is present, then the set of potentially-thrown exception types of the selection-statement is the union of I and the set of potentially-thrown exception types of the second substatement. i.e. the body of the else statement.

   Otherwise, the set of potentially-thrown exception types of the selection-statement is I.

   For example: The following statement has a set of potentially-thrown exceptions equal to { X }.

   if constexpr (true) {
     throw X{};
   } else {
     throw Y{};
   }
   

3. if consteval
   

   An if-statement of the form if consteval /compound-statement/ has a set of potentially-thrown exception types that is the set of potentially-thrown exception types of the compound-statement.

   An if-statement of the form if consteval /compound-statement/ else /statement/ has a set of potentially-thrown exception types that is equal to the union of the sets of potentially thrown exception types of compound-statement and statement, respectively.

   Note that the compound-statement is manifestly constant-evaluated and so is not currently permitted to throw exceptions and so could potentially be considered as not contributing to the set of potentially-thrown exception types.

   However, it is possible that we may want to support the ability to throw exceptions during constant-evaluation in future. See P3068R0 "Allowing exception throwing in constant-evaluation" for such a proposal.

   If we were to initially treat code within the manifestly-constant-evaluated branch as non-throwing then later changing it to be potentially-throwing would be a breaking change.

4. switch
   

   A switch statement of the form switch ( /init-statement/ /condition/ ) /statement/ or switch ( /condition/ ) /statement/ has a set of potentially thrown exception-types equal to union of the sets of potentially thrown exception types of the following parts:

   • init-statement (if present)
   • condition expression
   • statement

   Note that similarly to the if-statement we could modify this to consider the condition only if it is a potentially-reachable expression (i.e. the init-statement is absent or is not a flow-interrupted statement).

   Further, if the condition is either not reachable or is a flow-interrupted excpression then we could also consider any case or default labels associated with the switch-statement as unreachabel labels.

   The statement of a switch is not itself a potentially-reachable statement, although it may contain potentially-reachable sub-statements if there are labelled sub-statements. The set of potentially-thrown exception types of the statement only considers the potentially-reachable sub-statements.

5.6.7. iteration-statement

void example() throw(auto) {
  while (true) ;
  throw X{};
}

5.6.8. jump-statement

1. return statements
   

   A return statement has a set of potentially-thrown exception types equal to the union of the set of potentially-thrown exception types of the operand expression, and the set of potentially-thrown exception types from any implicit conversion or constructor call required to initialize the return-value.

   Note that there is an edge-case here that needs to be considered, where the operand to the return statement is a prvalue which is returned with guaranteed copy-elision and where the object has a potentially-throwing destructor. Normally, an expression that creates a pr-value includes the potentially-throwing types of both the call to the constructor, and the call to the destructor, as a statement containing that expression will also call the destructor at the end of the full-expression. However, for a return-value that is initialized with guaranteed copy-elision, the destructor will be invoked by the caller of the function, rather than the local function, and so the exception-specification of the return-value type should not be included in the calculation of the set of potentially-thrown exception types for the return statement.

   For example:

   struct Foo {
     Foo() throw(A);
     Foo(Foo&&) throw(B);
     ~Foo() throw(C);
   };
   
   Foo f() throw(auto) { // deduces to throw(A)
     return Foo{}; // constructor called here but not destructor
   }
   
   Foo g() throw(auto) { // deduces to throw(A, B, C)
     Foo f; // declaration statement potentially throws A (from constructor) and C (from destructor)
     return f; // move-constructor potentially called here, even if copy is elided due to NRVO
   }
   

   We also need to consider the case where the returned object is initialized using aggregate initialization, where there may be a whole tree of sub-expressions that potentially initialize sub-objects of the returned object.

   Any expression in such a return-statement that directly initializes an object or sub-object of the return-value that will be destroyed by the caller should not consider the exception-specification of that sub-object's type's destructor when computing the set of potentially-thrown exceptions of the return statement.

   Note that, while it may be possible that the return-statement may execute the destructor of some of these sub-objects in the case that initialization of a subsequent sub-object exits with an exception, we do not need to consider this case for the purposes of computing the potentially-thrown exceptions as these destructors will only be called in case there is an unwind due to another exception - if these destructors then throw their own exceptions during unwind then this results in an immediate call to std::terminate.

   For example:

   struct X {
     X() throw(A);
     ~X() throw(B);
   };
   struct Y {
     Y() throw(C);
     ~Y() throw(D);
   };
   
   struct Z {
     X x;
     Y y;
   };
   
   Z h() throw(auto) { // deduces to throw(A, C)
     return Z{X{}, Y{}};
   }
   

   In this example, if Z::x is initialized and then the call to Z::y's constructor throws then the Z::x destructor will be called, which could theoretically exit with an exception of type, B. However, since this can only happen while unwinding with an exception of type C, if Z::x.~X() exits with an exception during unwind then std::terminate() is called. So it is not possible for the function h() to exit with an exception of type B.

   As an aside, it would be useful to be able to make ill-formed any cases that could result in potential calls to std::terminate() due to an exception being thrown during unwind - at least in pursuit of the goal of embedded systems having no hidden calls to std::terminate(). How, and whether, to do this is an open-question.

2. co_return statements
   

   A co_return statement of the form co_return; has a set of potentially-thrown exception types equal to the set of potentially-thown exception types of the statement promise.return_void();, where promise is the current coroutine's promise object.

   A co_return statement of the form co_return /expr/ ;, where expr has type void has a set of potentially-thrown exception types equal to the union of the set of potentially-thrown exception types of expr and the set of potentially-thrown exception types of the statement promise.return_void(), where promise is the current coroutine's promise object.

   A co_return statement of the form co_return /expr-or-braced-init-list/ ;, where the operand is either an expression of non-void type or is a braced-init-list, has a set of potentially-thrown exception types equal to the set of potentially thrown exception types of the statement promise.return_value( /expr-or-braced-init-list/ );.

5.6.9. declaration-statement

1. simple-declaration
   

   A declaration statement that declares one or more block variables with automatic storage duration has a set of potentially-thrown exception types equal to the union of the sets of potentially thrown exception types of any initializer expressions and any calls to constructors or conversion operators required to initialize the local variables, and any potentially thrown exception types of calls to the destructors of the declared variables.

   A declaration statement that declares one or more block variables with either static storage duration or thread storage duration has a set of potentially-thrown exception types equal to the union of the sets of potentially-thrown exception types of any initializer expressions and any calls to constructors of conversion operators required to initialize the local variables, but does not include exception types of calls to the destructors of the declared variables.

   We do not include the exceptions thrown by destructors of static/thread_local variables because these destructors are not called from within the scope of a function that initializes these variables.

   Q. Initialization of variables with static storage duration needs to perform synchronization in multi-threaded environments in order to guard against data-races initializing the variable. Is it possible that operations on the synchronization primitives might fail with an implementation-defined or unspecified exception (in which case we would need to include this in the set of exception types) or can we assume that the synchronization will always succeed?

   A declaration statement that declares a constant expression (i.e. is declared with the constexpr specifier) has an empty set of potentially-thrown exception types, assuming that the program is ill-formed if a constant-evaluation exits with an exception.

2. asm-declaration
   

   The asm-declaration has implementation defined behaviour and, while in theory, on some implementations, an assembly declaration might be able to throw an exception, we cannot, in general, deduce anything about the set of exception types that might be thrown in a portable way.

   There are three possible options we take here:

   • the asm-declaration has implementation-defined behaviour, so the set of potentially-thrown exceptions from such a declaration should be implementation-defined.
   • the asm-declaration could potentially do anything (invoke a potentially-throwing function, implement some exception-throwing mechanics, etc.) so we should treat this as potentially throwing any type of exception.
   • the vast majority of asm-declaration usage is for implementing optimized, inline code, which won't throw any exceptions, so we could define it to be non-throwing.
   • we could make it ill-formed to use an asm-declaration in any context in which the exception-specification needs to be deduced.

   This paper suggests treating an asm-declaration statement as having an implementation-defined set of potentially-thrown exceptions as this at least allows the possibility of the implementation being able to analyse a declaration and deduce what exceptions might be thrown in an implementation-specific way.

   However, it would be worth a more detailed discussion within the Evolution sub-group about what the desired semantics are here.

5.6.10. try-block

5.6.11. init-statement

5.6.12. expression

1. General rules for expressions
   

   Expressions that have sub-expressions in general have a set of potentially-thrown exception types that includes the union of the sets of potentially-thrown exception types of the immediate-sub-expressions of that expression.

   Operator expressions or conversions that resolve to calls to user-defined operator functions have a set of potentially-thrown exception types of a function call expression to that user-defined operator function. Built-in implicit conversions and operators generally have an empty set of potentially-thrown exceptions.

2. Function call expressions
   

   Function call expressions have a set of potentially-thrown exception types equal to the union of the sets of potentially-thrown exception types of the following expressions:

   • the expressions provided as arguments to the function, including any default argument expressions.
   • any implicit conversion expression required to convert the argument to the corresponding parameter type, and
   • the postfix-expression immediately preceding the parenthesised argument-list

   unioned with the set of exception types listed in the postfix-expression's function type's or function-pointer type's exception-specification.

   If the postfix-expression has function type then the set of potentially-thrown exception types is taken from the exception-specification of the function declaration.

   If the postfix-expression has function-pointer or member-function-pointer type then the set of potentially-thrown exception types is taken from the exception-specification of the pointed-to function type. Note that this may be a superset of the set of exception types listed in the pointed-to function's exception specification.

   If the function or function-pointer has an dynamic exception-specification then the set of potentially-thrown exception types is the set { std::any_exception }, otherwise, if it has a static exception-specification then the set of potentially thrown exception types is the set of types listed in the exception specification.

   Note that if any parameter types of the function or function-pointer being called have a value category of prvalue then the set of potentially-thrown exception types will also include the exception types listed in the type's destructor's exception-specification, as per the next section.

3. prvalue expressions
   

   If an expression has a prvalue value category then the set of potentially thrown exception types of that expression includes the set of potentially thrown exception types of a function call expression to that object's destructor, unless that expression is the operand of a return statement of a function returning a prvalue of the same type as the operand and the operand is used to initialize the result object via copy-initialization.

   See the section on return statements for more details (in particular regarding aggregate initialization of return values).

4. Standard conversions
   

   The set of potentially-thrown exceptions from all standard conversions listed under [conv.general] is the empty set.

5. Constant expressions
   

   In C++23 it is not permitted for an exception to be thrown within the evaluation of a constant expression. If this is to remain the case, then we could assume that any manifestly constant expression has an empty set of potentially-thrown exceptions.

   However, it's possible that in the future we may decide to allow exceptions to be thrown during the evaluation of a constant expression. Although this may be limited to the cases where any thrown exception is caught within the same constant evaluation - similar to how dynamic memory allocation is allowed, as long as the memory is freed within the same constant evaluation. The paper P3068 "Allowing exception throwing in constant-evaluation" proposes such a change to the language.

   In order to allow for this possibility, and to avoid having adding this capability later be a breaking change, manifestly constant expressions should be treated the same as runtime-evaluated expressions for the purposes of computing the set of potentially-thrown exception types of that expression.

   However, the top-level expression that begins a new constant evaluation, such as initialization of a constexpr variable or the condition of an if constexpr statement, should be assumed to be non-throwing. An exception propagating out of such an expression would make the program ill-formed.

   For example:

   constexpr int parse_integer(const char* s) throw(parse_error) {
     int result = 0;
     do {
       if (!std::isdigit(*s)) throw parse_error{};
       result = 10 * result  + (*s - '0');
       ++s;
     } while (*s != '\0');
     return result;
   }
   
   int example_1() throw(auto) { // deduces to throw()
     constexpr int i = parse_integer("1234");
     return i;
   }
   
   int example_2() throw(auto) { // deduces to throw(parse_error)
     const int i = parse_integer("1234");
     return i;
   }
   
   int example_3() throw(auto) { // deduces to throw()
     if constexpr (parse_integer("1234") >= 10) {
       return 10;
     }
     return 0;
   }
   
   constexpr int example_4() throw(auto) { // deduces to throw(parse_error)
     if consteval {
       return parse_integer("1234");
     } else {
       return 0;
     }
   }
   

   In example_2(), even though a compiler could potentially evaluate the call to parse_integer() as a constant-expression, it is not required to do so and so could potentially have a runtime call to a function that is potentially-throwing.

   Also, if the function does happen to throw during a speculative constant execution of the function then the compiler falls back to inserting a runtime call to the function instead, rather than making the program ill-formed, like it would be if the invocation in example_1() or example_3() were to throw.

   For example, consider what the semantics should be if example_2() replaced the argument to parse_integer with "not-a-number" . In this case, we would expect that calling example_2 would throw parse_error at runtime. Simply changing the value of the string literal passed to parse_integer should not change the deduced exception-specification of the function.

   In example_4(), despite the call to the parse_integer() function being evaluated as a manifestly constant expression (inside the first-substatement of if consteval) this context is not being evaluated as a top-level constant evaluation and so might (one day) propagate the exception up to some caller that then handles the exception.

6. Throw expressions
   

   We need to consider both:

   • throw <expr> expressions that throw new exception objects, and
   • throw expressions that rethrow an existing exception.
   1. throw <expr>
      

      A throw-expression constructs and throws a new exception object of type equal to the decayed type of the operand expression.

      Some throw-expressions may require dynamic allocation of storage for the exception object, which might fail due to resource exhaustion. In this case, the throw expression may instead result in throwing an exception of type std::bad_alloc.

      Note that currently, the behaviour of a program that fails to allocate storage for a newly thrown exception is unspecified. However, the behaviour for failure to allocate/rethrow an exception_ptr is well-defined and so I would expect most implementations to do something similar - i.e. throw std::bad_alloc.

      This was discussed in the mailing list thread: https://lists.isocpp.org/core/2023/10/15012.php

      This paper proposes defining some forms of throw expressions as not requiring dynamic memory allocation, but instead requiring that implementations allocate the exception objects as automatic storage duration objects. This is necessary to be able to provide the guarantee to programs that particular throw expressions actually throw an exception of that type and do not throw an expression of some other type (like std::bad_alloc) and therefore that the set of potentially-thrown exception types is limited to the types of the actual thrown exceptions.

      1. Dynamic and Static throw expressions
         

         The function that contained the throw expression that created the exception object is called the "originating function".

         If the exception thrown by a throw-expression is either handled within the originating function or if the exception escapes the originating function (possibly after a number of catch/rethrow steps) and the function definition has a throw-specifier with a static exception specification (note this implies the exception type is listed in the throw-specification as otherwise the program would be ill-formed), then the throw expression is considered a static throw expression. All other throw-expressions are dynamic throw expressions.

         In general, this means that all throw expressions in functions with a throw-specifier on the definition that have a static exception specifications will be static throw expressions and throw-expressions in a function with a dynamic exception specification will be dynamic throw expressions unless they are caught locally within the originating function.

         For example: Both of the throw-expressions and the rethrow-expressions are all static throw expressions.

         void example1(int i) throw(Y, Z) {
           try {
             switch (i) {
             case 0:
               throw X{}; // static throw-expression: doesn't escape the function - locally handled
             case 1:
               throw Y{}; // static throw-expression: can escape the function (with rethrow)
             case 2:
               throw Z{}; // static throw-expression: escapes the function (not handled locally)
             }
           } catch (X) {
             // handled, not rethrown
           } catch (Y) {
             // handled, rethrown
             throw;
           }
         }
         
         

         Another example: this time with some dynamic exception specifications

         void example2(int i) throw(...) {
           try {
             switch (i) {
             case 0:
               throw X{}; // static throw-expression: doesn't escape the function - locally handled
             case 1:
               throw Y{}; // dynamic throw-expression: can escape the function (with rethrow)
             case 2:
               throw Z{}; // dynamic throw-expression: escapes the function (not handled locally)
             }
           } catch (X) {
             // handled, not rethrown
           } catch (Y) {
             // handled, rethrown
             throw;
           }
         }
         

         A dynamic throw expression allocates the storage in an unspecified way controlled by the implementation in the same way that storage for thrown exception objects are currently allocated. The exception object created by a dynamic throw expression is called a dynamic exception object.

         A static throw expression allocates the storage for the exception object with automatic storage duration. The exception object created by a static throw expression is called a static exception object. The scope of the storage ends after the end of the lifetime of the static exception object.

      2. Lifetime of exception objects created by static throw expressions
         

         According to [except.throw] p4

         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 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 the last one.

         For exception objects created by static throw expressions, we need to be able to deterministically compute their latest-possible point of destruction so that we know where to allocate the automatic storage-duration storage for that exception object.

         To allow the compiler to compute this point, we need to eliminate the possibility of the exception object's lifetime being dynamically extended by calling std::current_exception() and holding on to the std::exception_ptr. However, we still want to permit users to call std::current_exception() if desired.

         If the exception object being handled by the most-recently entered handler is a static exception object then a call to std::current_exception() returns an exception_ptr that references a dynamic exception object that is copied from the static exception object.

         Note that the current semantics of capturing the exception in a std::exception_ptr by calling std::current_exception() and throwing the captured exception by std::rethrow_exception() does not guarantee to throw the same exception object. An implementation is allowed to copy the current exception object into storage referenced by the returned std::exception_ptr, so this behaviour is consistent with existing semantics.

         Similarly, if a static exception object is rethrown by a throw; expression that is not a lexically associated rethrow of the active handler then the compiler may not be able to deduce that the current exception object escapes the current handler and should not be destroyed when the current handler exits.

         A lexically associated rethrow is a throw; expression that is a sub-statement of a handler's compound-statement and that is;

         • not inside the handler of a try-block nested within this handler; and
         • not inside the body of a lambda expression nested within this handler; and
         • not inside the body of a member function of a local class

         A throw; expression that is not a lexically associated rethrow throws a dynamic exception object. If the current exception is a static exception object then this will allocate a new dynamic exception object copied from the current static exception object.

         With those cases handled, we can now define that the lifetime of a static exception object ends deterministically upon exiting a handler for that exception through any means other that a lexically associated rethrow.

         Storage for a static exception object has automatic storage-duration.

         Generally, the storage for a static exception object will be allocated in the scope of the function that has the outer-most dynamic scope for a handler that can match the exception object's type, taking into account possible chains of catch/rethrow of the exception object.

         However, there are some cases where rethrowing an exception object may result in copying a static exception object from automatic storage duration storage allocated in an inner dynamic-scope to automatic storage duration allocated by an outer dynamic-scope.

         A caller of a function with a static exception specification will generally provide storage to the called function so that the called function can allocate the exception object in storage owned by the caller before it exits. If the caller is not the final handler of an exception (i.e. the lifetime of the exception object may escape the calling function), the caller may choose to reuse the storage provided to it by its caller as the storage it provides to the function it calls.

         1. Examples of static exception object lifetime and storage duration
            

            The following examples walk through some simple cases and describe how the exception object lifetime of static exception objects is intended to work.

            Given the following exception type, X, and function f(), which throws an instance of X:

            struct X {
              explicit X(int) noexcept;
              X(const X&) noexcept;
              ~X();
              int value;
            };
            
            extern int some_int;
            
            void f() throw(X) { throw X{some_int}; }
            

            Example 0: Consider the following case:

            void g0() throw(X) {
              f();
            }
            
            void h0() throw() {
              try { g0(); } catch (const X&) {}
            }
            

            In this case:

            • h0() allocates automatic-storage duration storage for an exception object of type X and provides the address of this storage to g0().
            • then g0() calls f() and provides the address provided by h0() to f()
            • if f() throws an exception, then it constructs the object directly into the storage provided by h0().
            • the exception unwinds through g0() and the handler in h0() is activated
            • the exception object is destroyed and the lifetime of the storage for the exception ends when the handler in h0() exits.

            Example 1: Consider the following case:

            void g1() throw(X) {
              try { f(); }
              catch (const X&) { throw; }
            }
            
            void h1() throw() {
              try { g1(); } catch (const X&) {}
            }
            

            In this case:

            • h1() allocates automatic-storage duration storage for an exception object of type X and provides the address of this storage to g1().
            • when g1() calls f() it forwards the address provided by h1() to f() and f() constructs the exception object directly into the storage provided by h1().
            • execution returns from f() and the handler in g1() is activated.
            • this handler then rethrows the exception - as the exception object is already constructed in the final location there is no need to copy the object.
            • execution then returns to h1() and its handler is activated
            • the exception object is destroyed when the handler in h1() exits

            Note that g1() in this case was able to pass the address of the storage for the exception object provided by h1() to f() because there was no other exception object being thrown by g1() whose lifetime overlaps with the lifetime of the exception object thrown by f().

            Example 2: Consider the following case:

            void g2() throw(X) {
              try { f(); }
              catch (const X& x) { throw x; }
            }
            
            void h2() throw() {
              try { g2(); } catch (const X&) {}
            }
            

            In this case:

            • The handler in g2() throws a new exception object insead of rethrowing the existing one
            • This means that the lifetime of the new exception object thrown by g2() overlaps the lifetime of the exception object thrown by f(), which is alive until the handler is exited.
            • This means that g2() cannot reuse the storage for the exception object provided by h2() to pass to f() and it needs to allocate its own automatic storage duration storage to provide to f() for any exception object
            • When f() throws an exception it constructs into the storage in g2() and then unwinds and activates the handler in g2().
            • The throw x; statement in g2()'s handler then constructs a new exception object in the storage provided by h2().
            • When the handler in g2() exits, the exception object thrown by f() is destroyed and its storage lifetime ends.
            • Control then unwinds to h2() and activates its handler.
            • When the handler in h2() exits, the exception object thrown by g2() is destroyed and its storage lifetime ends.

            Example 3: Consider the following case:

            void g3() throw(X) {
              try { f(); }
              catch (const X& x) {
                if (x.value < 0) {
                  throw X{0}; // throw a new object
                }
                throw; // rethrow
              }
            
              void h3() throw() {
                try { g3(); } catch (const X&) {}
              }
            

            In this case:

            • The handler in g3() conditionally either rethrows the current exception object or throws a new exception object.
            • In the case that the handler throws a new object, we have a similar case to g2() where there is overlap in lifetime between the exception object thrown by f() (whose lifetime ends at the end of the current handler) and the new exception object created by the throw X{0}; statement.
            • This means that we cannot reuse the storage that h3() provided to g3() for returning the exception as the storage that g3() provides to f() for returning its exception, even though there is another code-path in g3()'s handler that rethrows the current exception to h3().
            • Instead, g3() will need to allocate its own local storage to provide to f(), and then in both of the throw and rethrow-expressions, construct a new exception object in the storage provided by h3() to g3().
            • Note that in the rethrow-expression case, since the original exception object is about to be destroyed, we may be able to move-construct the new exception object from the original object instead of copy it as the throw; statement will exit the handler. Note: This may not be the case for all rethrow expressions.

            Example 4: Consider the following case:

            void g4() throw(X) {
              try { f(); }
              catch (const X& x) { if (x.value >= 0) throw; }
              throw X{0};
            }
            
            void h4() {
              try { g4(); } catch (const X&) {}
            }
            

            In this case:

            • It is similar to the above g3() example, except that this time, the new exception object is thrown from outside of the handler.
            • This means that the new exception object's lifetime no longer overlaps the lifetime of the exception object thrown by f(). If the exception object is rethrown by g4()'s handler then the exception object is already constructed in the right location. Otherwise, the handler exits and the exception object thrown by f() is destroyed before the new exception object is created by throw X{0}.
            • It is therefore safe for g4() to pass through the storage provided to it for the exception object to the call to f().
      3. Rules for throw expressions
         

         The set of potentially-thrown exception types of a throw expression is the union of

         • the set of potentially-thrown exception types of the operand expression
         • the type of exception thrown. i.e. std::decay_t<decltype(<expr>)>
         • the set of potentially-thrown exception type of copy-initialization of the exception-object

         Additionally, if the throw-expression is a dynamic-throw-expression then the set of potentially-thrown exception types also includes std::bad_alloc, which may be thrown if the implementation fails to allocate storage for the exception object.

   2. throw (rethrowing the currently handled exception)
      

      If the rethrow expression occurs lexically within the body of a handler and is not nested within a locally defined function body or a lambda expression body defined in the scope of that handler, then we say that the rethrow expression is associated with the inner-most enclosing handler.

      Otherwise, we say that the rethrow expression is unassociated with a handler.

      For example:

      void example() {
        throw; // unassociated - not inside handler
      
        try {
          throw; // unassociated - not inside handler
        } catch (A a) { // #1
          if (!can_handle(a)) {
            throw; // associated with #1
          }
      
          auto rethrow = [] {
            throw; // unassociated - inside lambda
          };
      
          struct LocalClass {
            static void Rethrow() {
              throw; // unassociated - inside nested function
            }
          };
        } catch (...) { // #2
          try {
            throw; // associated with #2
          } catch (B b) { // #3
            throw; // associated with #3
          }
        }
      }
      

      If a rethrow expression is associated with a handler then we potentially have more static information about the set of possible exception types that might be thrown by that expression than a rethrow expression that is unassociated with a handler.

      We can compute the set of exception types that might be thrown by such a rethrow exception based on the set of exception-types that may propagate out of the try-block and based on the exception types that may be handled by handlers earlier in the sequence of handlers for that try-block.

      1. Unreachable handlers
         

         One of the interesting cases to handle is when we can statically determine whether the handler is unreachable. This can happen in one of two cases:

         • When an earlier handler matches an unambiguous base-class of the later handler's exception-declaration type and will therefore preferentially match any exception types that would be handled by the later later handler.
         • When the set of potentially thrown exception types of the try-block's compound-statement is a finite set (i.e. does not contain contain std::any_exception) and there are no types in that finite set that match this handler and that do not match any earlier handler.

         In this case, there is the question of what the set of potentially-thrown exception types should be for a rethrow expression that is associated with such an unreachable handler.

         As the handler itself is statically determined to be unreachable, the body of the handler's compound-statement does not contribute to the overall set of potentially-thrown exception types of the try-block, so we might say "it doesn't matter".

         However, if we consider the ability to query the set of potentially-thrown exception types using declthrow() then a program might want to query within the context of the handler, what types might be thrown by a rethrow expression. i.e. declthrow(throw)....

         The ability to query whether or not a given handler is reachable can be useful in eliminating code that would otherwise be ill-formed, or that we want to avoid instantiating to reduce compile-times.

         For example: Code for implementing the P2300 std::execution::then() algorithm needs to determine whether invoking the transformation function might throw and only if it does then invoke the receiver with set_error(), otherwise it should not form a call to set_error().

         For example:

         template<typename... Args>
         void then_receiver::set_value(Args&&... args) noexcept {
           try {
             if constexpr (std::is_void_v<decltype(this->func(std::forward<Args>(args)...)>) {
               this->func(std::forward<Args>(args)...);
               std::execution::set_value(this->receiver);
             } else {
               std::execution::set_value(this->receiver, this->func(std::forward<Args>(args)...));
             }
           } catch (...) {
             // Only want to instantiate the call to set_error() if there are actually
             // any errors possible.
             if constexpr (noexcept(this->func(std::forward<Args>(args)...)) {
               std::execution::set_error(this->receiver, std::current_exception());
             }
           }
         }
         

         Note that here we need to repeat the essential parts of the body of the try-block in a constexpr if condition noexcept expression to determine whether or not the catch(...) block was reachable. And while, for this example, the body only has one such expression, it is relatively easy to conceive of try-block logic that could be much more involved.

         If, instead, we were able to query whether or not the handler was reachable by querying the set of exception types that might be thrown by throw; within that handler, then we could avoid having to duplicate the body expressions in the constexpr if condition.

         For example:

         template<typename... Args>
         void then_receiver::set_value(Args&&... args) noexcept {
           try {
             if constexpr (std::is_void_v<decltype(this->func(std::forward<Args>(args)...)>) {
               this->func(std::forward<Args>(args)...);
               std::execution::set_value(this->get_receiver());
             } else {
               std::execution::set_value(this->get_receiver(), this->func(std::forward<Args>(args)...));
             }
           } catch (...) {
             // Only want to instantiate the call to set_error() if there are actually
             // any errors possible.
             //
             // declthrow(throw)... will produce the empty pack if the try-block body
             // is not potentially-throwing.
             if constexpr (sizeof...(declthrow(throw)) != 0) {
               std::execution::set_error(this->get_receiver(), std::current_exception());
             }
           }
         }
         

         Another design direction that could be taken here is to allow writing the catch-all handler as a template catch that is instantiated with an exception declaration of std::exception_ptr. This could build upon the alternative suggested earlier for using std::exception_ptr in place of std::any_exception for indicating the set of potenially-thrown exception types for a call to a function with a dynamic exception specification.

         If the body of the try-block had a set of potentially-thrown exception types that was empty then the template catch handler would not be instantiated.

         For example:

         template<typename... Args>
         void then_receiver::set_value(Args&&... args) noexcept {
           try {
             if constexpr (std::is_void_v<decltype(this->func(std::forward<Args>(args)...)>) {
               this->func(std::forward<Args>(args)...);
               std::execution::set_value(this->get_receiver());
             } else {
               std::execution::set_value(this->get_receiver(), this->func(std::forward<Args>(args)...));
             }
           } template catch (auto& error) {
             // Catch-block is only instantiated if there are any exceptions that might be thrown from code in the try-block.
             // If an exception is thrown by a 'throw(...)' function then 'error' will have type 'std::exception_ptr&'.
             std::execution::set_error(this->get_receiver(), std::move(error));
           }
         }
         

      2. Rethrow expression rules
         

         If the rethrow expression is unassociated with a handler then the set of potentially-thrown exception types for that rethrow expression is equal to the set { std::any_exception }. This is because the expression could potentially be executed within the dynamic scope of any handler and thus could rethrow any caught exception type.

         Otherwise, if the rethrow expression is associated with a handler, H, then;

         Let E be the set of potentially-thrown exception types of the compound-statement of the try-block associated with H.

         Let H-pre be the set of handlers associated with the same try-block as H that precede H in the try-block's handler-seq.

         Let X be initially the empty set.

         For each type, e, in the set E

         • if e is std::any_exception then
           • if the exception-declaration of H is ... then add std::any_exception to the set X
           • otherwise, let h be the type named in H's exception-declaration
             • if any handler in H-pre matches exceptions of type h then, do nothing (this handler is unreachable)
             • otherwise, if h is of non-class type or is a final class then add h to X
             • otherwise add std::any_exception to X (it might handle an unbounded set of potential exceptions derived from h)
         • otherwise,
           • if any handler in H-pre matches exceptions of type e, then do-nothing
           • otherwise, if H matches exceptions of type e, then add e to X
           • otherwise, do nothing

         The set of potentially-thrown exception types for a rethrow expression associated with H is X.

         Note that this algorithm can produce a set of potentially-thrown exception types that includes a list of concrete exception types as well as std::any_exception.

         Note that these rules make the result of a declthrow(throw) expression context dependent.

         Note that each instantiation of a template handler has a separate set, X, of potentially-thrown exception types that it handles. Thus a lexically-associated rethrow expression within a template handler will have different sets of potentially-rethrown exception types for different instantiations. The sets of potentially-rethrown exception types for each instantiation of a template handler will be disjoint.

      3. Examples
         

         Given the following declarations:

         struct A {};
         struct B : A {};
         struct C : A {};
         struct D : B, C {};
         struct E final {};
         
         template<typename... Ts>
         void throws() throw(Ts...);
         

         Example 1: static exception list, catch(…)

         try {
           throws<A>();
         } catch (...) {
           throw; // declthrow -> { A }
         }
         

         Example 2: static exception list, typed handler, unreachable catch (…)

         try {
           throws<A>();
         } catch (A) {
           throw; // declthrow -> { A }
         } catch (...) {
           throw; // declthrow -> { }
         }
         

         Example 3: multiple exceptions caught by single handler

         try {
           throws<A, B>();
         } catch (A) {
           throw; // declthrow -> { A, B }
         } catch (...) {
           throw; // declthrow -> { }
         }
         

         Example 4: multiple exceptions caught by multiple handlers

         try {
           throws<A, B>();
         } catch (B) {
           throw; // declthrow -> { B }
         } catch (A) {
           throw; // declthrow -> { A }
         } catch  (...) {
           throw; // declthrow - > { }
         }
         

         Example 5: ambiguous bases

         try {
           throws<D>();
         } catch (A) {
           throw; // declthrow -> { } - empty because A is ambiguous base of D and so doesn't match
         } catch (B) {
           throw; // declthrow -> { D } - catch (B) unambiguously handles exceptions of type D
         } catch (C) {
           throw; // declthrow -> { } - already handled by catch (B)
         } catch (D) {
           throw; // declthrow -> { } - already handled by catch (B)
         }
         

         Example 6: mixed static/dynamic

         try {
           throws<A>();
           throws<std::any_exception>();
         } catch (A) {
           throw; // declthrow -> { std::any_exception, A }
         } catch (...) {
           throw; // declthrow -> { std::any_exception }
         }
         

         Example 7: dynamic throw with final class

         try {
           throws<std::any_exception>();
         } catch (E) {
           throw; // declthrow -> { E }
         } catch (...) {
           throw; // declthrow -> { std::any_exception }
         }
         

         Example 8: mixed static/dynamic with final class

         try {
           throws<E>();
           throws<std::any_exception>();
         } catch (E) {
           throw; // declthrow -> { E }
         } catch (...) {
           throw; // declthrow -> { std::any_exception }
         }
         

         Example 9: template handler, single type

         try {
           throws<A>();
         } template catch (auto e) { // Instantiated for types { A }
           throw; // declthrow -> { decltype(e) }
         }
         

         Example 10: template handler, multiple types

         try {
           throws<A, B, C, D>();
         } template catch (auto e) { // Instantiated for following types { D, B, C, A }
           throw; // declthrow -> { decltype(e) }
         }
         

         Example 11: template handler + non-template handler

         try {
           throws<A, B, C, D>();
         } catch (B) {
           throw;  // declthrow -> { B, D }
         } template catch (auto e) { // Instantiated for { C, A }
           throw; // declthrow -> { decltype(e) } - either { A } or { C }
         }
         

         Example 12: template handler + non-template handler + dynamic throw

         try {
           throws<A, B, C, D>();
           throws<std::any_exception>();
         } catch (B) {
           throw; // declthrow -> { B, D, std::any_exception }
         } template catch (auto e) { // Instantiated for { C, A }
           throw; // declthrow -> { decltype(e) }
         } catch (...) {
           throw; // declthrow -> { std::any_exception }
         }
         

         Note that for example 12 the template handler is instantiated for types A and C and rethrowing within the template handler only rethrows those concrete types, despite the possibility of the throws<std::any_exception>() potentially being able to throw exceptions of type derived from either C or A.

         Example 13: constrained template handler + non-template handler + dynamic throw

         try {
           throws<A, B, C, D>();
           throws<std::any_exception>();
         } template catch (std::one_of<B, C> auto e) { // instantiated for { B, C }
           throw; // declthrow -> { decltype(e) }
         } catch (A) {
           throw; // declthrow -> { A, D, std::any_exception }
         } catch (...) {
           throw; // declthrow -> { std::any_exception }
         }
         

         Note that with this example, the compiler tries to instantiate the template handler for each of the static exception types, but substitution fails for types A and D, succeeding only for types B and C.

         The handler for A matches A and D and potentially also an unbounded set of other types derived from A.

         The final handler matches an unbounded set of types not derived from A.

7. await-expression
   

   An expression of the form co_await /expression/ has a set of potentially-thrown exception types equal to union of the sets of potentially-thrown exception types of each of the sub-expressions that the await-expression de-composes into.

   Including:

   • The operand expression
   • The call to p.await_transform(expr), if applicable.
   • The call to member or non-member operator co_await, if applicable.
   • The calls to await_ready(), await_suspend() and await_resume().
   • A call to the destructors of any temporary objects created as a result of one of the above sub-expressions

   Note that if one of the sub-expressions is an interrupted-flow expression then we still consider the set of potentially-thrown exception types of subsequently evaluated sub-expressions even though they may be unreachable. If we want to consider ignoring unreachable sub-expressions then this should be applied more generally across all expression evaluation.

8. yield-expression
   

   A co_yield /assignment-expression/ or co_yield /braced-init-list/ expression has a set of potentially-thrown exception types equal to the union of the sets of the potentially thrown exception types of the expression co_await promise.yield_value(expr), where promise is an lvalue reference that refers to the current coroutine's promise object.

   Note that the call to promise.await_transform() is not applied as part of a co_yield expression, so does not contribute to the set of exception types.

9. dynamic_cast
   

   Basically, any dynamic_cast expression to reference-type that could fail the runtime check has a set of potentially-thrown exception types equal to the set { std::bad_cast }.

   A dynamic_cast expression that is a cast to pointer-type or that was a cast to a reference type that would not fail (e.g. because it was a cast to an unambiguous base-class of the operand's class type) has an empty set of potentially-throw exception types.

   Note that the wording of dynamic_cast currently permits implementations to throw some type that would match a handler of type std::bad_cast, which currently permits throwing types derived from std::bad_cast. This change would require that the exception thrown was exactly the type std::bad_cast.

10. typeid
    

    A typeid(/type-id/) expression has an empty set of potentially-thrown exception types.

    A typeid(/expression/) expression has a set of potentially-thrown exception types equal to { std::bad_typeid }. This exception may be thrown if the operand of the typeid expression is the result of dereferencing a null pointer of non-cv type.

    While this behaviour matches the current specification of typeid expressions, supporting the ability to ask for the type of a dereferenced null pointer seems to be of questionable value. The wording for the builtin unary * operator in [expr.unary.op] says that the behaviour of performing an indirection on a pointer that does not point to a function or object is undefined except as specified in [expr.typeid].

    So, literally the only thing you can do with an lvalue produced by dereferencing a null pointer is pass it to a typeid expression.

    It may be worth exploring whether we can either deprecate/remove this behaviour from typeid (which would be a breaking change) or whether we can add a new form of typeid(/expression/) that has a precondition that the expression does result in an glvalue that refers to an object or function. i.e. such that passing a dereferenced null pointer is undefined-behaviour.

    This would allow the set of potentially-thrown exception types for a typeid expression to be empty.

11. Name expressions
    

    Expressions that simply name an object

    These expressions include:

    • id-expression
    • this

    These expressions have an empty set of potentially thrown exception types.

12. Lambda expressions
    

    The set of potentially-thrown exception types of a lambda expression are the union of the set of potentially thrown exception types of the initializers of the lambda captures.

5.7.1. Template argument deduction

auto example(auto f) throw(X) {
  try {
    f();
  }
  template catch (auto err) {
    return err;
  }

  throw X{};
}

example([] throw() {}); // deduces return type to be 'void' as return statement never instantiated
example([] throw(int) {}); // deduces return type to be 'int' - single return statement
example([] throw(int, long) {}); // ill-formed: multiple return statements with different deduced return types

5.7.2. Matching dynamic exception objects

5.7.3. Ordering of instantiated handlers

5.8.1. ABI of virtual functions with differing exception specifications

struct base {
  virtual base* clone();
};
struct derived : base {
  derived* clone() override;
};

struct base {
  virtual base* clone();
};
struct other_base {
  virtual std::string to_string();
};
struct derived : other_base, base {
  derived* clone() override;
};

5.10.1. Coroutine promise object handling for static exception objects

{
  /promise-type/ promise /promise-constructor-arguments/ ;
  try {
    co_await promise.initial_suspend();
    /function-body/
  } catch (...) {
    if (!initial-await-resume-called)
      throw;
    promise.unhandled_exception();
  }
final_suspend:
  co_await promise.final_suspend();
}

{
  /promise-type/ promise /promise-constructor-arguments/ ;
  try {
    co_await promise.initial_suspend();
    /function-body/
  } template catch (auto& ex) {
    // Static exception objects caught here
    if (!initial-await-resume-called)
      throw;

    if constexpr (can_handle_exception</promise-type/, decltype(ex)>) {
      promise.unhandled_exception(ex);
    } else if (can_handle_exception</promise-type/, std::exception_ptr>) {
      promise.unhandled_exception(std::make_exception_ptr(std::move(ex)));
    } else {
      promise.unhandled_exception();
    }
  } catch (...) {
    // Dynamic exception objects caught here
    if (!initial-await-resume-called)
      throw;

    constexpr bool is_handler_reachable = sizeof...(declthrow(throw)) > 0;
    if constexpr (is_handler_reachable) {
      if constexpr (can_handle_exception</promise-type/, std::exception_ptr>) {
        promise.unhandled_exception(std::current_exception());
      } else {
        promise.unhandled_exception();
      }
    }
  }
final_suspend:
  co_await promise.final_suspend();
}

template<typename P, typename E>
concept can_handle_exception =
  requires(P& promise, E& ex) {
    p.unhandled_exception(ex);
  };

struct my_promise_type {

  // ... rest of promise type omitted for brevity

  void unhandled_exception(one_of<A, B> auto& ex) throw() {
    constexpr std::size_t index = std::same_as<decltype(ex), A&> ? 2 : 3;
    result.emplace<index>(std::move(ex));
  }

  std::variant<std::monostate, value_type, A, B> result;
};

5.10.2. Computing the exception specification of a coroutine with a deduced throw specification

5.11.1. Nothrow queries

5.11.2. std::is_function and std::is_member_function_pointer

5.11.3. Additional traits

6.2.1. Background On How Exceptions work in Java

public void foo() throws IOException {
    // ...
}

6.2.2. Criticisms of Java Checked exceptions

1. Versioning and evolvability of interfaces
   

   The problem with versioning and evolvability of interfaces with Java checked exceptions arises when an API that is initially released and is in use by users later wants to evolve to add additional error-conditions for a given operation.

   Consider a function that initially specifies that it throws A, B or C but then later wants to add some features that means it can fail in new ways and wants to now add D to the list. Adding D to the list of potentially thrown exceptions is now a breaking change, potentially requiring updating each caller to either handle that exception, or if it does not handle that error, then adding that exception to its throw specification.

   This in turn can require recursively updating many calling functions with new error-conditions.

   To avoid having to go and update callers to add additional exceptions to their throw specifiers programmers often just listed throws Exception which allows it to transparently throw any type of exception - which basically defeats the purpose of checked exceptions.

   This is arguably already the status quo in C++, where a dynamic exception specification already just says "I can throw anything".

   This allows C++ functions to later be modified to throw new exceptions without that introducing a compilation error. However, in many cases this can still be a breaking change if existing callers were not expecting this new exception to be thrown - potentially leading to bugs relating to unhandled exceptions.

   One of the arguments against checked exceptions in Java was that for a lot of use-cases people don't want to handle the exceptions. If something fails then they just want to let these errors propagate up to some top-level handler and just let it log/report the error. Forcing the programmer to write a lot of boiler-plate to accurately list exception types in cases where callers do not handle specific errors does not add a lot of benefit and so writing throws Exception may make sense in that situation.

   This paper holds the position that adding a new exception to the list of potentially thrown exceptions is indeed a potentially breaking change to a function, regardless of whether this is represented in the signature of the function or not.

   The set of ways in which a function can potentially fail is a key aspect of its interface and should be considered as part of its design.

   The design proposed in this paper provides a few additional tools compared to Java to help manage evolution of a function's exception specifications.

   It provides the ability to introspect the set of potentially-thrown exceptions for some expression via declthrow, allowing computation of derived exception specifications in terms of the exception specifications of other functions. This can help with allowing the signatures of calling functions to automatically adapt when callees are modified to throw additional exception types.

   It also provides the ability to deduce the exception specification from the body by using throw(auto). This is largely just a convenience to manually writing out complex declthrow expressions to compute the exception specification, but requires that the body of the function is visible to the caller.

   Functions that want to have an extensible set of error-conditions that can be emitted can also take the approach of using types that have extensible values, such as std::error_code, which can allow new error-categories and error-conditions to be represented in a single value in an extensible way.

   This requires calling code to manually check for each error-condition, however, and have a fallback for error-conditions it doesn't yet support. If a new error-condition should require callers to handle it then it may be better to represent this as a new exception type which callers need to handle.

2. Scalability of checked exceptions
   

   The second issue discussed in the [Trouble] interview was the use of checked exceptions in large systems.

   The point was made that checked exceptions look good in the small when you are looking at leaf functions with a few exception-types and their callers, but when it comes to composing multiple high-level systems it is easy for those high-level calls to end up with 50+ exception-types being listed in each function, affecting readability of the code.

   To avoid such large lists of exceptions, Java code ends up either just listing base-class exceptions like throws Exception, or ends up catching and ignoring the exception via a catch with an empty handler.

   Note that the status quo in C++ is that any function not marked noexcept has an exception specification that is the equivalent of Java's throws Exception, so if dynamic exceptions are suitable for your use-cases then you can continue to use them.

   With this paper, if you want to use throw-specifiers and static exceptions all the way up into the high-level systems then it's possible there would indeed be a need to list a large number of exceptions in such high-level functions.

   There are additional tools in C++ that could help make this more manageable compared to Java, however.

   • Pack aliases, proposed by [P3115R0], could be used to define shorter names for reusable sets of exceptions thrown by each subsystem. Then high-level functions could list the pack-alias names, throw(foo_errors..., bar_errors..., baz_errors...) instead of listing every exception that might be thrown by each subsystem.
   • Use of throw(auto) could be used on functions that compose multiple systems to allow the compiler to compute the exception-specification - with the tradeoff that these functions must have their definitions visible to users. Alternatively, use of throw specfications using declthrow() queries could be used in the declaration if separate compilation is required.
   • Multiple subsystems could throw types like std::error_code to represent error conditions so that there is overlap between sets of potentially-thrown exceptions from different subsystems and the errors.

7.6.1. Avoiding overhead implied by std::current_exception() and throw;

1. Using catch static to reduce overhead of dynamic exception facilities
   

   We could consider adding some kind of annotation/specifier to a handler that allows the author to indicate that they will not be making use of the dynamic exception facilities within the handler and that the compiler can optimise on this basis.

   For example:

   try { something(); }
   catch static (const X& ex) {
     // user promises not to call std::current_exception() or dynamic-rethrow in here
   }
   

   Annotating a handler thusly signals to the compiler that, while this handler is the active handler, that:

   • evaluating a call to std::current_exception() will return an unspecified std::exception_ptr. It is unspecified since if the handler has caught a dynamic exception object then there may not be any overhead in registering the exception object if the act of throwing the exception already registered it.
   • evaluating a dynamic-rethrow expression either calls std::terminate() or is undefined-behaviour (which one is TBD).

   Note that the handler can still rethrow the exception by evaluating a throw; expression that is lexically associated with the handler - the compiler knows where to go to get the exception object in this case.

2. Catching std::exception_ptr as an alternative to calling std::current_exception()
   

   Another avenue to explore that might reduce the need for thread-local access is to allow the user to write:

   try { something(); }
   catch /* static */ (std::exception_ptr e) {
     // stash 'e' somewhere
   }
   

   as an alternative to writing:

   try { something(); }
   catch (...) {
     auto e = std::current_exception();
     // stash 'e' somewhere
   }
   

   The alternative formulation potentially allows the compiler to directly construct the exception_ptr and pass it to the handler without needing to access the thread-local state.

   If the thrown exception object was a dynamic-exception-object then it might not be any more efficient and so might lower to calling std::current_exception() and just passing the result.

   If the thrown exception object was a static-exception-object, however, then the compiler could directly construct a new dynamic-exception-object from the static-exception-object and pass the pointer withouth having to access the thread-locals. e.g. as if by std::make_exception_ptr(obj).

   On the throwing side, we could consider making a throw expr expression where argument is a possibly-cv-qualified std::exception_ptr as equivalent to calling std::rethrow_exception().

   This would have great benefits for generic programming if we could treat std::exception_ptr as if it were just another exception object that could be thrown/caught.

   The major challenge to a syntax like this, however, is that it would be a breaking change. There may be code-bases out there that are intentionally throwing an exception of type std::exception_ptr and catching std::exception_ptr rather than using std::rethrow_exception() to rethrow the contained dynamic-exception-object.

   Adoping the semantics described above would mean their catch(std::exception_ptr) handler would now start matching all exceptions, not just a thrown std::exception_ptr.

   Also, if we decided that, like catch(...), that a catch(std::exception_ptr) must appear as the last handler in the sequence of handlers for a try-block, then it may cause existing code to become ill-formed if catch(std::exception_ptr) does not appear as the last handler.

   A quick search in https://codesearch.isocpp.org/ showed 2 matches for handlers that were catching a std::exception_ptr.

   One was a unit-test¹ in cpprestsdk that was making sure that when an exception_ptr was being rethrown by an async task library that it was using std::rethrow_exception(eptr) instead of throw eptr and was checking that the catch(std::exception_ptr) handler was not being entered when the exception was rethrown.

   The other was similarly for an async framework in the Ice project which was intentionally catching an exception_ptr and then immediately calling std::rethrow_exception() to propagate the exception. Upon further investigation, I found an issue² that indicated a desire to move away from this and a search of the latest version of the codebase yielded no usage.

   A search of github yielded one other hit:

   • heisenberg-go hnsw_wrapper.cc This looks like it might be a bug and may have intended to write catch(const std::exception&) as I could not find any throw expressions that were throwing an exception_ptr in the project.

   Usage of this pattern in open-source projects does not seem to be wide-spread. While not representative of code-bases at large, it may be worth considering a syntax like this to both allow freestanding platforms that don't have access to thread-locals an alternative API for obtaining the current exception an an exception_ptr and also to simplify generic code that needs to deal both dynamic and generic exceptions by giving them similar forms.

7.6.2. Avoiding overhead implied by std::unhandled_exceptions()

{
  scope_failure cancel_on_fail{[&] { transaction.RollBack(); }};

  for (auto& x : items) {
    transaction.execute(generate_sql(x)); // might throw
  }
}

struct __cxa_eh_globals {
  __cxa_exception* caughtExceptions;
  unsigned int uncaughtExceptions;
};

// Gets a pointer to the current thread's exception state
__cxa_eh_globals* __cxa_get_globals(void);

++__cxa_get_globals()->uncaughtExceptions;

--__cxa_get_globals()->uncaughtExceptions;

template<std::invocable F>
struct scope_failure {
  F func;

  // Normal destruction
  ~scope_failure() {}

  // Unwind destruction
  ~scope_failure(std::unexpect_t) {
    func();
  }
};

template<std::invocable F>
scope_failure(F) -> scope_failure<F>;

7.9.1. Whether implementations add noexcept to "Throws: Nothing" functions can now affect well-formedness of a program

void example(const std::vector<int>& v) throw() {
  int sum = 0;
  for (size_t i = 0; i < v.size(); ++i) {
    sum += v[i];
  }
  return sum;
}

void example2(const std::vector<int>& v) throw() try {
  int sum = 0;
  for (size_t i = 0; i < v.size(); ++i) {
    sum += v[i];
  }
  return sum;
} catch (...) { std::terminate(); }

[[noreturn]] void nothrow_unreachable() noexcept {
  std::unreachable();
}

7.9.2. Should implementations be allowed to strengthen "Throws: something" exception specification to a static exception specification?

std::uint32_t walk_graph(const std::vector<std::optional<std::uint32_t>>& v, std::uint32_t start_at) throw() {
  std::uint32_t current = start_at;
  try {
    while (true) {
      current = v.at(current).value();
    }
  }
  catch (std::out_of_range) {}
  catch (std::bad_optional_access) [}
  catch (...) { [] noexcept { std::unreachable(); }(); } // This line would be unnecessary with static exception specifications
  return current;
}

7.9.3. Usage of the standard library in functions with static throw-specifications will be painful without more noexcept

7.9.4. Function-wrapper types

1. std::function
   

   This type is parameterised by a function signature of form R(Args...).

   This class is undefined for function signatures of the form R(Args...) noexcept, largely because doing so would have no effecton the resulting class.

   The std::function::operator() call can throw the std::bad_function_call exception if invoked on a std::function instance that is empty and so the operator() could not be marked noexcept anyway.

   The existing std::function class could be used as-is to wrap functions and function-objects whose call-operator as a non-empty static-exception specification. Although we would need to extend the function-pointer casting rules to allow casting from void(*)() throw(X) to void(*)() throw(...).

   We could also consider defining an additional partial-specialization of std::function that allowed specifying a function-signature with a static-exception specification and then computed a static-exception specification for operator() that added std::bad_function_call to that exception-list.

2. std::copyable_function and std::move_only_function
   

   These types are parameterised on a function-type that inclues the exception-specification.

   We would need to add additional partial specializations for cases where the function type passed as the first template argument has a non-empty static exception specification to have this apply that exception specification to its operator(), and also to require that the wrapped callable has a compatible exception specification.

3. std::reference_wrapper
   

   This type could have its operator() modified to have a deduced exception specification so that if the referenced object has an operator() with a static exception specification then the reference_wrapper::operator() also has an equivalent exception specification.

4. Function objects
   

   The following types could be extended to have call operators annotated with throw(auto) to have them deduce the exception specification based on the exception specification of the underlying operator implementation.

   Arithmetic function objects

   • std::plus
   • std::minus
   • std::multiplies
   • std::divides
   • std::modulus
   • std::negate

   Comparison function object

   • std::less
   • std::greater
   • std::less_equal
   • std::greater_equal
   • std::equal_to
   • std::not_equal_to
   • std::compare_three_way

   Logical Operations

   • std::logical_and
   • std::logical_or
   • std::logical_not

   Bitwise Operations

   • std::bit_and
   • std::bit_or
   • std::bit_xor
   • std::bit_not

7.9.5. Algorithms

8.1.1. Inline Jump Tables

int divide(int num, int den) throw(divide_by_zero, overflow) {
  if (den == 0) throw divide_by_zero{};
  if (den == -1 && num == INT_MIN) throw overflow{};
  return num/den;
}

int x, y;

int example() {
  try {
    int result = divide(x, y);
    return 2 * result;
  } catch (divide_by_zero e) {
    return -1;
  } catch (overflow) {
    return -2;
  }
}

x:
  .data 4

y:
  .data 4

example:
  mov edi, dword ptr [x]   ; Load 'x' into register for param 1
  mov esi, dword ptr [y]   ; Load 'y' into register for param 2
  call divide    ; Jump to 'divide' and push address of .JUMP_TABLE onto stack
.JUMP_TABLE:     ; Each entry is a 'JMP rel32' encoded instruction which is 5 bytes
  jmp .SUCCESS   ; entry[0] - success path
  jmp .ERR_0     ; entry[1] - error path for divide_by_zero
  jmp .ERR_1     ; entry[2] - error path for overflow
.SUCCESS:
  # result is in eax
  mul eax, 2
  ret
.ERR_0:
  mov eax, -1
  ret
.ERR_1:
  mov eax, -2
  ret

divide:
  ;# NOTE: [rsp] points to address of .JUMP_TABLE
  test esi, esi
  je .THROW1
  cmp esi, -1
  jne .LBL1:
  cmp edi, 0x7fffffff
  jne .THROW2
.LBL1:
  mov eax, edi
  cdq
  idiv esi
  ret       ; return to entry[0]
.THROW1:
  ; [rsp] contains address of entry[0] instruction
  ; need to add '5' (size of JMP instruction) to this to get address of entry[1]
  ; do this in-place to avoid using an extra register to compute the address
  add qword ptr [rsp], 5
  ret       ; return to entry[1]
.THROW2:
  ; [rsp] contains address of entry[0] instruction
  ; need to add '10' (size of 2 * JMP instruction) to this to get address of entry[2]
  ; do this in-place to avoid using an extra register to compute the address
  add qword ptr [rsp], 10
  ret       ; return to entry[2]

example:
  mov edi, dword ptr [x]   ; Load 'x' into register for param 1
  mov esi, dword ptr [y]   ; Load 'y' into register for param 2
  call divide    ; Jump to 'divide' and push address of .JUMP_TABLE onto stack
.JUMP_TABLE:     ; Each entry is a 'JMP rel32' encoded instruction which is 5 bytes
  jmp .SUCCESS   ; entry[0] - success path
  jmp .ERR_0     ; entry[1] - error path for divide_by_zero
.ERR_1:
  mov eax, -2.   ; entry[2] - error path for overflow (inlined as last jump table entry)
  ret
.SUCCESS:
  ; result is in eax
  mul eax, 2
  ret
.ERR_0:
  mov eax, -1
  ret

8.1.2. "NOP Stuffing" Jump Tables

example:
  mov edi, dword ptr [x]   ; Load 'x' into register for param 1
  mov esi, dword ptr [y]   ; Load 'y' into register for param 2
  call divide    ; Jump to 'divide' and push address of .JUMP_TABLE onto stack
.DATA_NOP
  nop DWORD (.JUMP_TABLE - .DATA_NOP) ; 3-byte prefix + 4-bytes jump table offset
  mul eax, 2
  ret

.JUMP_TABLE:     ; Each entry of table is a pointer to return-address
  data DWORD (.ERR_0 - .DATA_NOP)
  data DWORD (.ERR_1 - .DATA_NOP)

.ERR_0:
  mov eax, -1.  ; entry[1] - error path for divide_by_zero
  ret

.ERR_1:
  mov eax, -2.  ; entry[2] - error path for overflow
  ret

divide:
  ; NOTE: [rsp] points to address of nop encoding offset to .JUMP_TABLE
  test esi, esi
  je .THROW1
  cmp esi, -1
  jne .LBL1:
  cmp edi, 0x7fffffff
  jne .THROW2
.LBL1:
  mov eax, edi
  cdq
  idiv esi
  ret       ; return to nop instruction (normal return)
.THROW1:
  ; [rsp] contains address of nop instruction (i.e. return address)
  mov rax, QWORD PTR [rsp]       ; load the address of the nop instruction
  mov edx, DWORD PTR [rax+3]     ; load the offset-to-jump-table part of the nop instruction (assuming 7 byte encoding, last 4 bytes is offset)
  mov edx, DWORD PTR [rax+rdx]   ; load the offset in entry[0] of table
  add QWORD PTR [rsp], rdx       ; add offset to return-address
  ret                            ; return to unwind path for 'divide_by_zero'
.THROW2:
  mov rax, QWORD PTR [rsp]       ; load the address of the nop instruction
  mov edx, DWORD PTR [rax+3]     ; load the offset-to-jump-table part of the nop instruction (assuming 7 byte encoding, last 4 bytes is offset)
  mov edx, DWORD PTR [rax+rdx+4] ; load the offset in entry[1] of table
  add QWORD PTR [rsp], rdx       ; add offset to return-address
  ret                            ; return to unwind path for 'overflow'