One of the ideas of exceptions is that not all intermediate functions have to list (or even know) all exceptions, which can happen. Whether that idea has merit or whether it is a bad idea is a different question, but one would have to answer it first before annotating all thrown exceptions.   As a food for thought:   One probably has a "hierarchical" relationship of which exceptions can happen:   All functions in my component may throw, if memory low. The database functions may throw, if there is a database error. The file functions may throw, if disk full or not reachable or there is an access permission error.   One can narrow it down further for specific functions. If you start to annotate, you probably want some convenience.   Could e.g. either be by exception inheritance, by (exception type) constraints, by member function/class inheritance, by hierarchical namespace or by something else?   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 10.05.2025 13:11 Betreff:Re: [std-proposals] noexcept has gotten a bit hairy -- I want a compiler error An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; If you want to do something with exceptions, I think it's far more productive to annotate what type of exceptions a function can throw as opposed to that it can just throw exceptions. And make not throwing exceptions the default.   Exceptions are a fundamentally broken concept and since their inception the same problems keep popping up. Adding features to exception feels like a waste of time, like putting lipstick on a pig.   If you want to fix something we need to address the basic concepts that it got wrong.   Other modern language that decided not to have exceptions are safer because of it, and it was the best design choice they could have made.   My 2c is kill it.