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