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: Sat, 4 Jan 2025 20:08:00 +0200
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <vlbte2$imdo$1@dont-email.me>
References: <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>
 <vl9eq7$1n1d$1@dont-email.me>
 <cone.1735956395.711486.303344.1000@ripper.email-scan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 04 Jan 2025 19:08:02 +0100 (CET)
Injection-Info: dont-email.me; posting-host="95744ba089c10b6da397ef529c0fdc13";
	logging-data="612792"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX192CURCBvVQFFvV6Ytd5KBiYrPmfwyXt44="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:puU71LpqehAtQ4M/qs9FEEW1MeM=
Content-Language: en-US
In-Reply-To: <cone.1735956395.711486.303344.1000@ripper.email-scan.com>
Bytes: 3207

On 04.01.2025 04:06, Sam wrote:
> Paavo Helde writes:
> 
>>
>> Anyway, avoiding uncaught exceptions is easy, one just has to place 
>> catch(...) in main() and in all thread functions. Problem solved.
> 
> Sure, catch(...) deals with it. But it gives you nothing useful to work 
> with. A valiant attempt to send a bat-signal to std::current_exception 
> will eke out a few useful bits, if one's lucky, but the end result will 
> just be more spaghetti code.

If an exception has reached the top-level catch, then this means that 
all lower levels (which have more knowledge about the context) have not 
been able to catch and handle it. In the top-level catch there is little 
hope I could do anything smarter, typically I just need to report or log 
an error message.

So there is no need to differentiate between different types of 
exceptions or to extract any useful bits from them, all I need is an 
error message. For that I have a little helper function which can be 
called from inside catch(...) and which handles various exception base 
classes and falls back to typeid(e).name() for unknown types. Actually I 
am not interested in exception types at all at this point, not to speak 
about enforcing them somehow. If there appear new exception base 
classes, I add support for them in the helper function, not trying to 
reduce their usage.

[...]

> 
> I dunno, maybe something like:
> 
> typedef throws(ClassA, ClassB) AlgoThrownClasses;
> 
> Then you go ahead and declare your algorithm:
> 
> void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)

That's the first good idea from you in this discussion. I still do not 
see much point in exception specifications, but such a typedef would at 
least make life easier for me on this Alternate Earth.

PS. Nowadays they prefer `using` instead of `typedef`.