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@lists.isocpp.org>
Gesendet: Fr 28.08.2026 10:39
Betreff: Re: [std-proposals] fine-control exception/error/UB handling on function boundary
An: std-proposals@lists.isocpp.org;
CC: Tiago Freire <tmiguelf@hotmail.com>; Zamfir Yonchev <zamfir.yonchev@gmail.com>; std-proposals@lists.isocpp.org;

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?