Deutsch   English   Français   Italiano  
<67d0fcdaa9aa19d56b3237d2bf2030bc838ecb5b.camel@gmail.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Sun, 05 Jan 2025 07:14:44 +0800
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <67d0fcdaa9aa19d56b3237d2bf2030bc838ecb5b.camel@gmail.com>
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>
	 <vlbte2$imdo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 05 Jan 2025 00:14:45 +0100 (CET)
Injection-Info: dont-email.me; posting-host="799ce123a0e16044e5ba469ce30d4436";
	logging-data="710155"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EyR4mrqUY8Ey5Rttl+kLt"
User-Agent: Evolution 3.54.2 (3.54.2-1.fc41)
Cancel-Lock: sha1:22KLZU+y3OgZPwjAGISCnqM0U54=
In-Reply-To: <vlbte2$imdo$1@dont-email.me>
Bytes: 3759

On Sat, 2025-01-04 at 20:08 +0200, Paavo Helde wrote:
> On 04.01.2025 04:06, Sam wrote:
> > Paavo Helde writes:
> >=20
> > >=20
> > > Anyway, avoiding uncaught exceptions is easy, one just has to place=
=20
> > > catch(...) in main() and in all thread functions. Problem solved.
> >=20
> > Sure, catch(...) deals with it. But it gives you nothing useful to work=
=20
> > with. A valiant attempt to send a bat-signal to std::current_exception=
=20
> > will eke out a few useful bits, if one's lucky, but the end result will=
=20
> > just be more spaghetti code.
>=20
> If an exception has reached the top-level catch, then this means that=20
> all lower levels (which have more knowledge about the context) have not=
=20
> been able to catch and handle it. In the top-level catch there is little=
=20
> hope I could do anything smarter, typically I just need to report or log=
=20
> an error message.
>=20
> So there is no need to differentiate between different types of=20
> exceptions or to extract any useful bits from them, all I need is an=20
> error message. For that I have a little helper function which can be=20
> called from inside catch(...) and which handles various exception base=
=20
> classes and falls back to typeid(e).name() for unknown types. Actually I=
=20
> am not interested in exception types at all at this point, not to speak=
=20
> about enforcing them somehow. If there appear new exception base=20
> classes, I add support for them in the helper function, not trying to=20
> reduce their usage.

This is an interrupt, I didn't read the context of this thread.

std::except was a big blunder (not invented by B.S.). It is similar to=C2=
=A0
errno or a global object, you set it up and throw. C++ hide it in a=C2=A0
beautiful theory called 'advanced error handling'.... long story.

> [...]
>=20
> >=20
> > I dunno, maybe something like:
> >=20
> > typedef throws(ClassA, ClassB) AlgoThrownClasses;
> >=20
> > Then you go ahead and declare your algorithm:
> >=20
> > void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>=20
> That's the first good idea from you in this discussion. I still do not=
=20
> see much point in exception specifications, but such a typedef would at=
=20
> least make life easier for me on this Alternate Earth.
>=20
> PS. Nowadays they prefer `using` instead of `typedef`.
>=20
>=20