This is, i believe, in context of contact violation handling, trying to
nondestructively figure out if there is a landing pad for a given
exception, which is supposedly implementable on the itanium ABI.

On Mon, May 29, 2023, 08:01 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> But would ignoring those 13 conditions be implementable in each case for
> each implementation? Can the stack be unwound in each case? To what level?
>
>
>
> E.g. What happens, when during an exit std::atexit functions throw an
> exception? Is the exit stopped to 'locally' be recovered? Is the exit
> continued afterwards?
>
>
>
> Would the possibility of a try throw at the caller site bloat up exception
> handling code in functions, where an exception with those exceptions may
> occur or even in all functions in between?
>
>
>
> Perhaps you could try to write for each of the cases alternative code,
> which is compiled under the current rules, but has the proposed effect to
> show that it is implementable. E.g. if a handler is missing, insert one,
> etc.
>
>
>
> You will find that in many cases
>
> - the local handling is not the right place for handling
>
> - the code within sub-functions cannot be made to work with and without
> try throw
>
> - It will not be possible to leave some objects in a healthy/valid state,
> so real recovery is not possible
>
>
>
> Probably the best you will be able to do for some of the abandoned
> exceptions is to exchange std::terminate with a global handler of your
> choosing, not for recovery, but for customized termination.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Andrew Tomazos via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 29.05.2023 04:16
> *Betreff:* [std-proposals] Idea of try_throw (Conditional Throw
> Statement)?
> *An:* sotrdg sotrdg via Std-Proposals <std-proposals_at_[hidden]>;
> *CC:* Andrew Tomazos <andrewtomazos_at_[hidden]>;
> Imagine a C++ keyword `try_throw` and a try-throw-statement with the
> following syntax:
>
> try-throw-statement:
> try_throw assignment-expression_opt ;
>
> If one of the 13 conditions listed in [except.terminate] (
> https://eel.is/c++draft/except.terminate) applies, then a
> try-throw-statement has no effect (and its expression is not evaluated).
>
> Otherwise, it has the effect of a normal throw expression statement and
> control is passed to the appropriate catch handler.
>
> This would mean you could write code like:
>
> if (/* something bad */) {
> /* clean up */
> try_throw std::runtime_error(/*...*/);
> /* attempt to recover locally */
> return /* ... */;
> }
>
> In essence, it allows for falling back to local recovery when a catch
> handler is unavailable. (Normally, in those situations the global
> terminate handler is called, and local recovery is not permitted.)
>
> Any thoughts?
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>