Re: We have a new standard!

On 03/01/2025 14: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.

That's wrong on many levels.
First, what you think should be "obvious" now might not have been obvious at the time the relevant decisions were made - it's a lot easier to see problems with hindsight than to predict them in advance.
Secondly, what /you/ think is "obvious" can differ greatly from what other people think is obvious.  To /me/, it's obvious that dynamic exceptions are a bad idea in any compiled language suitable for systems programming.  Exceptions that can pass through functions are "hidden gotos" - clearly worse even than explicit "gotos".  Rather, it is "obvious" that the language should have had something akin to std::expected<> from the start, with syntactic sugar to reduce the boilerplate code to a minimal and compiler implementations using flag registers to get optimised code generation.  That's /obvious/.
Thirdly, you are again mistaking how Java supports exceptions. Unchecked exceptions in Java are not validated at compile time in any way.
Fourthly, you appear to be completely ignorant about the tools available in the early days of C++.  C++ had to work alongside existing linkers and related tools, which would not have been able to support such a system.  Even with more modern tools, to get a good system of checked exceptions without having to add an enormous source code burden on the programmer, you would need some kind of compiled interface file tracking exactly which exceptions each function could throw and pass on. Otherwise if "foo" calls "bar" and passes on any exception thrown by "bar" up the chain to the caller of "foo", you'd need to change the declaration of "foo" every time the list of exceptions throwable by "bar" (or any function it calls) changes.  That would be a nightmare in maintenance, and loses the whole point of exceptions.
Fifthly, you appear to be completely ignorant of how C++ is intended to work beside code written in C - the exception mechanism in C++ is designed to be transparent to C functions.  Without that, there would be no object code level compatibility.

Instead of that we have the current state of affairs where the only 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.
 

There is no such requirement in C++.  For convenience, the exceptions thrown by standard library functions are all derived from std::exception, but you are free to throw whatever types you like.