Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Paavo Helde <eesnimi@osa.pri.ee>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Fri, 3 Jan 2025 21:46:15 +0200
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <vl9eq7$1n1d$1@dont-email.me>
References: <vl66j6$3cbce$1@dont-email.me> <vl6gbr$3e4rd$1@dont-email.me>
 <cone.1735849245.346442.281052.1000@ripper.email-scan.com>
 <vl8m0u$3t4v1$1@dont-email.me>
 <cone.1735909901.753978.294757.1000@ripper.email-scan.com>
 <vl8sfi$3u4fh$1@dont-email.me>
 <cone.1735919451.379621.297354.1000@ripper.email-scan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 03 Jan 2025 20:46:16 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f5de04e1063ab8773d1d03a38709de46";
	logging-data="56365"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/b0ekNTWGeMT4apxh32TO81n5aE9UCjU8="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:dnH1Ow01Kc13kVQTc3Sj3U5AhuI=
Content-Language: en-US
In-Reply-To: <cone.1735919451.379621.297354.1000@ripper.email-scan.com>
Bytes: 3739

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?