The general information from static analysis, whether all exceptions are handled, is not very useful.   At the top of main (or the threads) there may be a catch-all. Exceptions may be caught in-between and differently rethrown. For the program terminate may be acceptable for all or some exceptions, then all those are handled by default.   Rather than checking whether exceptions are handled, the more interesting question is, whether program state is still okay.   Not all code uses RAII perfectly.   {   char c;   int handle = AkquireResource(&c);   if (hopefullyNever)     throw std::exception();   ReleaseResource(handle); }   Resource is leaked. This can lead to deadlocks, this can also lead to dangling pointers (c!).   Such code has to be identified and written in a RAII fashion. It is a larger danger for code with exceptions, as there may be no explicit throw or explicit premature return between resource akquisition and release. So programmers have to be aware, where exceptions may happen.   exception-safe code is not only a topic for standard member functions.   Not sure, if any tooling may help with that.   Should some code like ReleaseResource be forced to be destructor only? It could be in a function called by destructors.   -----Ursprüngliche Nachricht----- Von:Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 29.08.2026 02:13 Betreff:Re: [std-proposals] fine-control exception/error/UB handling on function boundary An:std-proposals_at_[hidden]; CC:Jonathan Grant <jgrantonline_at_[hidden]>; On 28/08/2026 11:08, Sebastian Wittmeier via Std-Proposals wrote: > h(g(f())) > >   > > One important philosophy of exceptions is that code in-between - like the function g - does not have to care, what kind of exceptions are thrown by f, as long as h handles it. > > You could argue that the code within g does not have to care, but at compile-time the function-signature (or some other metadata of the function) should show it. I'd find it useful there was some advanced static analysis as well as function-signature documentation (to check the they match), and also to verify at compile-time. BTW, I tried using compile_assert() to validate known exceptions were handled at compile-time, but it couldn't Regards Jonathan > > You can also say that is a bad philosophy, if you think so. > > >   > >     -----Ursprüngliche Nachricht----- >     *Von:*Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> >     *Gesendet:*Fr 28.08.2026 10:39 >     *Betreff:*Re: [std-proposals] fine-control exception/error/UB handling on function boundary >     *An:*std-proposals_at_[hidden]; >     *CC:*Tiago Freire <tmiguelf_at_[hidden]>; Zamfir Yonchev <zamfir.yonchev_at_[hidden]>; std-proposals_at_[hidden]; >     Well but why? >     Because there are generally 2 camps. >     1. People who don't use exceptions because they are fundamentally broken. >     2. People who use exceptions because they don't care. >       >     There is however a minority third camp. >     I don't like exceptions, but am forced to use them to work, because you don't work by yourself and codebases exists before I worked there. >     And I would kill to be able to specify a list of possible exceptions at the interference level to be able to validate the code is exception safe. >       >     I care if my code is safe, but we are in a minority that thinks there is a problem that needs to be solved, but even if you do exceptions are still a dumpster fire and you would never use it if you could so why bother? > > -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals