-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.8.3.1). May also be called directly by the +be abandoned for any of several reasons (15.5.1), in effect immediately after +evaluating the throw-expression (18.8.3.1). May also be called directly by the program.
It is not clear what is "in effect". It was clear in previous drafts where paragraphs +
It is not clear what is "in effect". It was clear in previous drafts where paragraphs 1 and 2 read:
@@ -61,18 +61,18 @@ that was in effect immediately after evaluating the throw-expression". triggered by the implementation - no throw-expression involved.
- In case a destructor throws during stack unwinding we have two throw-expressions + 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 throw +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 throw be involved even indirectly). -Next,, paragraph 2 says +Next, , paragraph 2 says Required behavior: A terminate_handler shall terminate execution @@ -84,33 +84,33 @@ 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 +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.-The here mentioned wording changes by N3189 in regard to
The part "in effect immediately after evaluating the throw-expression" -should be removed and the quoted reference top1 -were done for a better separation of effects (Effects element) and additional normative +The here mentioned wording changes by N3189 in regard to p1 +were done for a better separation of effects (Effects element) and additional normative wording explanations (Remarks element), there was no meaning change intended. Further, -there was already a defect existing in the previous wording, which was not updated when -further situations where defined, when std::terminate where supposed to be -called by the implementation. +there was already a defect existing in the previous wording, which was not updated when +further situations where defined, when std::terminate where supposed to be +called by the implementation. -need to be part of the effects element where it refers to the current terminate_handler +should be removed and the quoted reference to +need to be part of the effects element where it refers to the current terminate_handler function, so should be moved just after "Effects: Calls the current terminate_handler function." -It seems ok to allow a termination handler to exit via an exception, but the +It seems ok to allow a termination handler to exit via an exception, but the suggested idiom should better be replaced by a more simpler one based on evaluating the current exception pointer in the terminate handler, e.g.