[C++29][except] Dissolve the exceptions clause into the rest of the document

[AlisdairM]

Exceptions are a control flow, just like if, while, and goto. They belong somewhere in [stmt], with the exception (no pun) of [except.throw] as a throw_expression is literally an expression, so move [except.throw] to follow [expr.delete] as a unary operator.

Exception specifications are nothing to do with control flow, and are entirely a function specifier that feeds the noexcept operator, so belong somewhere in [dcl]. See #7308.

The specification for the uncaught_exceptions function is the wrong place to augment the rules for when an exception is active. They belong in [except.handle] around p9/p10 that define what it means for an exception to be active, leaving the library wording to define the semantics of this function without duplication. See #7276.

The terminate function is now used for more than just failures of the exception handling machinery. Its description should be updated accordingly. See #7281.

Once the specification of terminate has been updated, it is no longer specifically an exception feature, and should be relocated to the end of [basic.start] Start and termination. That completes dissolving this clause into the rest of the standard.

Jens noted that exceptions really did belong in [stmt] from the start, but they were still an experimental feature as C++ was being standardized in 1997, unlike most the rest of that clause, so were conservatively given their own top level clause in case of complications. We are not past time to put them back where they belong.

Note that it would be good to land #7276 for C++26, as that will complete moving all the specification of handling an activ exception into a single place. While it would be nice to also land #7281 and resolve its fix-me, that is less impactful.

[jensmaurer]

A try-block is a statement and thus belongs into [stmt]. The control flow argument is bogus, because a throw-expression also causes control flow, but is not (and should not be) in [stmt].

[AlisdairM]

I was thinking of throw_expession as analogous to goto, but you are right --- it is there in the name, it is an expression.
Thanks!

Updated the issue text to follow the discussion.

[jensmaurer]

a throw_expression is literally an expression, so move [except.throw] to follow [expr.delete] as a unary operator.

No. We already have [expr.throw], which covers the throw-expression. However, there are other ways how exceptions can be thrown that don't involve a throw-expression, e.g. by dynamic_cast or typeid.

So, at least the syntactic parts of [except.handle], plus the try-block grammar snippet, should go into [stmt]. I don't yet have a good idea where [except.throw] and [except.ctor] should go. Maybe some of it ("there is an exception object") is so fundamental it should go into [basic.exec]. std::terminate definitely belongs there.

[tkoeppe]

@jensmaurer Do you mean that the library specification of std::terminate should go into [basic.exec], or merely the references to when it is invoked? The specification sounds like it should go into [support], doesn't it?

[tkoeppe]

... where it already is, of course: [support.exception]

[jensmaurer]

I'm talking about [except.terminate]. But maybe the large note there should go into [terminate] and the paragraph about partial stack unwinding should go with stack unwinding (or wherever we say we call std::terminate in the "no handler found" etc. situations).

And uncaught_exceptions could go to the library entirely.

[AlisdairM]

I have pushed a new PR with the full planned dissolution here: #7320.

I will update the main description to more accurately follow these changes shortly. One of the more notable changes now is that following Jens's advice, most of the control flow aspects are moved into [basic.exec], where I placed them between single/multi-threaded execution and program start and termination.

Also worth checking is whether all the cross-references hold up. There were 4 old cross-references to [except] that I had to fix.