Re: We have a new standard!

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.