| Deutsch English Français Italiano |
|
<A9ecnWZ5up01DuX6nZ2dnZfqn_ednZ2d@giganews.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 04 Jan 2025 01:49:28 +0000 Subject: Re: We have a new standard! Newsgroups: comp.lang.c++ References: <vl5lvf$39de4$1@dont-email.me> <vl625a$3bj9b$1@dont-email.me> <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> From: Ross Finlayson <ross.a.finlayson@gmail.com> Date: Fri, 3 Jan 2025 17:49:30 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <vl8sfi$3u4fh$1@dont-email.me> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <A9ecnWZ5up01DuX6nZ2dnZfqn_ednZ2d@giganews.com> Lines: 65 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-Vts0nKtLVTBgcMqcatJxxiw8Ic7vXZmOJluE79HRp+wDX6LnC1b7rXucgxrt/rxLg7kCSpq6Mjl47al!Z9WTfRNiWG8t2sPIRERfiq/3Pdt5guZpiL0rCpfgvKPssywAO+DTkHLWNMtlEqEUsZcyM0Gryxz4 X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 4283 On 01/03/2025 06:33 AM, Paavo Helde wrote: > On 03.01.2025 15:11, Sam wrote: >> David Brown writes: >> >>> I think it became fairly quickly apparent that "throw(...)" >>> specifiers were not as useful in practice as had been hoped, and >>> relatively few programmers used them except in the form "throw()". >>> So "throw(...)" was deprecated in C++11 and has been valid until >>> C++17 (with compilers implementations being free to accept it as a >>> non-standard extension far beyond that). >> >> It should be painfully obvious that the right thing to do should've >> been to merge throw specifications into function signatures, allowing >> exception handling to be validated at compile-time, i.e. what Java >> did. Instead of that we have the current state of affairs where the only > > It might be obvious to you, but not for everybody. What exact problem > can be solved by validating thrown exception classes at compile time? > 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? > > > > half-assed solution is to have all exception classes derived from a > > superclass, i.e. std::exception, and then play musical chairs to catch > > exceptions. > > My Java is rusty, but isn't it in Java that all exception classes must > be derived from a single superclass (Throwable)? > > I think exceptions are critical, i.e. critically important and necessary, simply because they can declare what otherwise results that code that doesn't model what makes it undefined behavior is undefined behavior, and any interface has an arbitrarily not-impossible failure mode. So, when Rust was like "we're safe and no exceptions" I was like "that's un-safe and un-usual". As are more than half of their "crates". When Google style was like "we don't use exceptions" I was like "did you forget setjmp and longjmp". Anyways the exception specification particularly, and everyone knows it's a real pain sometimes because you have to learn the semantics and how to reasonably catch exceptions besides die-ing, or swallow-ing, just like handling "structured return codes" or today's usual idea "exit 0 or exit 1", has that it's like "fire and forget protocols", who have no idea when they make huge puddles. Then, C++ with "throw whatever you want", I understand that entirely complicates the type-analysis, as with regards to closures in types as it were, and that having everything extend std::exception and throwing refs as it were, seems the way of things though that always confused me why it was refs instead of pointers, figuring that should've come out the scope, anyways I'm a big fan of exceptions they're very important rules.