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.