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. 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?