Sujet : Re: We have a new standard!
De : eesnimi (at) *nospam* osa.pri.ee (Paavo Helde)
Groupes : comp.lang.c++Date : 03. Jan 2025, 20:46:15
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vl9eq7$1n1d$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
On 03.01.2025 17:50, Sam wrote:
Paavo Helde writes:
>
It might be obvious to you, but not for everybody. What exact problem can be solved by validating thrown exception classes at compile time?
Ummm… Making it logically impossible to throw an uncaught exception? The code will refuse to compile because it will be ill-formed. Getting rid of std::uncaught_exception(), completely?
I have never used std::uncaught_exception(). Well, I think I tried to use it once, 20 years ago, but it did not work in any useful way IIRC.
Anyway, avoiding uncaught exceptions is easy, one just has to place catch(...) in main() and in all thread functions. Problem solved.
Double exceptions appearing during stack unwind are more tricky. Here some compiler support enforcing noexcept would be nice indeed. But this would not need any more detailed exception specifications.
And how would a developer of a base class know which exceptions I might want to throw from an overridden virtual function in a derived class, which might be developed and compiled fully separately from the base class?
The developer doesn't need to figure it out, the compiler will tell him.
You misunderstood my point. Yes, the compiler will refuse to compile my code because a new algorithm implementation throws a new kind of SocketException or whatever. So what next? The goal is to compile my code, not to get compiler errors.
Now I have to change the signatures of the umpteen functions in the call stack in umpteen classes in umpteen projects to let the new required exception through (or translate it to something else via an even more questionable hack). The point is that those umpteen functions could not care less about what exceptions go through them as they will just pass them all through. So what's the point?
At any frame in the call stack, if I want to catch a specific exception, I can do that. Everything else goes up to the top-level catch(...) and gets logged or converted to an error message as appropriate.
Why should I arbitrarily restrict what exceptions I can throw in some function? Seems to me like arbitrarily deciding that some functions may not use switch() and some other functions may not use while(). Why?