Remarks: Called by the implementation when exception handling must
be abandoned for any of several reasons (15.5.1), in effect
immediately after evaluating the throw-expression (18.104.22.168).
May also be called directly by the program.
It is not clear what is "in effect". It was clear in previous drafts
where paragraphs 1 and 2 read:
Called by the implementation when exception handling must be
for any of several reasons (15.5.1). May also be called directly
Effects: Calls the terminate_handler function in effect
after evaluating the throw-expression (22.214.171.124), if called by the
implementation, or calls the current terminate_handler function,
called by the program.
It was changed by N3189. The same applies to function unexpected (D.
11.4, paragraph 1).
Assuming the previous wording is still intended, the wording can be
"unless std::terminate is called bythe program, we will use the
that was in effect immediately after evaluating the throw-
This assumes that there is some throw-expression connected to every
situation that triggers the call to std::terminate. But this is not
In case std::thread is assigned to or destroyed while being joinable
there is no throw-expression involved.
In case std::uexpected is called by the program, std::terminate is
triggered by the implementation - no throw-expression involved.
In case a destructor throws during stack unwinding we have two throw-
expressions involved. Which one is referred to?
In case std::nested_exception::rethrow_nested is called for an object
that has captured no exception, there is no throw-expression involved
directly (and may no trow be involved even indirectly).
Next, 126.96.36.199, paragraph 2 says
"Required behavior: A terminate_handler shall terminate execution
program without returning to the caller."
This seems to allow that the function may exit by throwing an
exception (because word "return" implies a normal return). One could
argue that words "terminate execution of the program" are sufficient,
but then why "without returning to the caller" would be mentioned. In
case such handler throws, noexcept specification in function
std::terminate is violated, and std::terminate would be called
recursively - should std::abort not be called in case of recursive
std::terminate call? On the other hand some controlled recursion could
be useful, like in the following technique:
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
I withdraw this interpretation, I would say that the wording allows an
exception to leave the terminate handler and it is OK this way. I still
think that your suggested idiom is not so reasonable given the less
fragile idiom based on std::exception_ptr() evaluation without any
further roundtrip to terminate again.