Re: We have a new standard!

On 01/03/2025 06:06 PM, Sam wrote:

Paavo Helde writes:
>

On 03.01.2025 17:50, Sam wrote:

Paavo Helde writes:

>
It might be obvious to you, but not for everybody. What exact
problem can be solved by validating thrown exception classes at
compile time?

>
Ummm… Making it logically impossible to throw an uncaught exception?
The code will refuse to compile because it will be ill-formed.
Getting rid of std::uncaught_exception(), completely?

>
I have never used std::uncaught_exception().

>
It's not typically used directly. Its primary user is your suffering C++
compiler, when it automatically injects a call to it in the code path
for uncaught exceptions.
>

                                             Well, I think I tried to
use it once, 20 years ago, but it did not work in any useful way IIRC.
>
Anyway, avoiding uncaught exceptions is easy, one just has to place
catch(...) in main() and in all thread functions. Problem solved.

>
Sure, catch(...) deals with it. But it gives you nothing useful to work
with. A valiant attempt to send a bat-signal to std::current_exception
will eke out a few useful bits, if one's lucky, but the end result will
just be more spaghetti code.
>
If C++, the language, forced uncaught exception to be ill-formed then
this will pretty much negate the need for a wildcard catch, solving that
problem. I suppose that a wildcard catch can still be around, if someone
needed it. But it'll be viewed as an indication of lack of core C++
knowledge and experience.
>

Double exceptions appearing during stack unwind are more tricky. Here
some compiler support enforcing noexcept would be nice indeed. But
this would not need any more detailed exception specifications.

>
I think that double exceptions would naturally be minimized, in my ideal
C++ world. I think that exception-correctness would naturally eliminate
them. Exception correctness enforces strict exception handling, making
it more prominent.
>
Think about it. Destructors would be a hard noexcept. C++ then forces
you to write an explicit catch for any exceptions that get thrown from a
destructor. Mission accomplished.
>

                                                               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?

>
The developer doesn't need to figure it out, the compiler will tell him.

>
You misunderstood my point. Yes, the compiler will refuse to compile
my code because a new algorithm implementation throws a new kind of
SocketException or whatever. So what next?

>
Fix the code, that's what's next.
>

                           The goal is to compile my code, not to get
compiler errors.

>
The only way to achieve the lofty goal is to fix the compiler errors.
So: fix them. This is no different than any other ABI break from a new
library version.
>

Now I have to change the signatures of the umpteen functions in the
call stack in umpteen classes in umpteen projects to let the new
required exception through (or translate it to something else via an
even more questionable hack).

>
This is the logically equivalent to a changed return type, a changed
parameter, or a type of any other object that's used commonly in the code.
>
I recall one time when I replaced a container that was used for
important stuff in my code. A whole bunch of functions returned this
container. The container used to be a std::list. It was now a
std::vector. I don't remember exactly how many functions referenced it.
Maybe 30-40, or so.
>
Now, I'm going to tell you something that will blow you away. Prepare to
be shocked. This revelation will rock your world. Make sure you're
sitting down. Seal all exits. Cancel the three-ring circus. Secure all
elephants in the zoo. Guess what?
>
I did not have to monotonically go through and update the 30-40 function
declarations.
>
Are you still with us, my friend? You survived such a shocking
reveleation?Good! Because, you see, C++ has this highly advanced,
space-age tool that only a select few C++ gurus know about.
>
It's called a "typedef". These days it's also known as a "using"
declaration.
>
All I had to do is change one typedef, and all those functions were now
returning a vector. After changing
>
typedef std::list<Widget> all_my_widgets;
>
to
>
typedef std::vector<Widget> all_my_widgets;
>
Then all the existing code, referencing "all_my_widgets", or
"all_my_widgets::iterator", or "all_my_widget_instance.begin()", and so
on – guess what? It's still compiled! OMIGOSH!!!!
>
I think I only needed to fix one or two things, that specifically
depended on the actual underlying implementation. The rest of the code,
that didn't care for the actual container, remained unchanged, and only
had to be recompiled.
>
So, in your case, your "umpteen functions" just need to be declared
correctly. Here's what happened on Alternate Earth, where exceptions
were actually implemented like that: the point you raised would've been
identified as a pain point early on, and something analogous to
"typedef", but for throw specifiers, was added to the language.
>
I dunno, maybe something like:
>
typedef throws(ClassA, ClassB) AlgoThrownClasses;
>
Then you go ahead and declare your algorithm:
>
void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>
I'm now married to the actual syntax or grammar, that's just the syntax
that was used on Earth 2. Earth 3 used different syntax, and I don't
recall what it is, so I'll just focus on Earth 2's implementation. The
code you would write, on Earth 2, would use the alias:
>
void my_function_that_uses_algorithmm() throws(AlgoThrownClasses)
{
   algorithm_info_t info;
>
   my_algorithm(info);
}
>
Your Earth 2 doppelganger also threw its own exceptions:
>
void my_function_that_uses_algorithm() throws(AlgoThrownClasses,MyError)
>
All callers of my_function_that_uses_algorithm(), on Earth 2, used the
same alias.
>
* Pedantic note: your Earth 2 doppelganger will achieve greybeard status
by using, instead, "typedef throws(AlgoThrownClasses, MyError)
MyThrownClasses" and use that alias, instead.
>
Now, my friend, guess what happened if the algorithm was updated on
Earth 2 to throw a different exception:
>
typedef throws(ClassA, ClassB, ClassC) AlgoThrownClasses;
>
You'll be shocked and awed to learn that all those "umpteen functions"
will still compile just fine, on Earth 2.
>
The only additional work was done wherever in your code, on Earth 2, you
caught and handled the exceptions from the algorithms. And your
suffering C++ compiler, on Earth 2, will tell you exactly where the code
needs to be fixed, because it will now have an uncaught exception.
>
I wish I could move to Earth 2. But, on Earth 2, Donald Trump just won
his third term, and their border is already closed, and will be closed
for the foreseeable future.
>
Now, another thing just occured to me: what if the algorithm was changed
and it no longer throws one of the exceptions on Earth 2, and the
typedef alias was changed accordingly?
>
Well, in the existing code this results in a catch for an exception that
cannot possibly be thrown.
>
On Earth 2 it's an informational compiler diagnostic.
>
-Wall -Werror happily deals with it, on Earth 2.
>

                    The point is that those umpteen functions could
not care less about what exceptions go through them as they will just
pass them all through. So what's the point?

>
The point is that Earth 2 designed C++ properly, and on Earth 2 they
learned how to use C++ properly.
>

At any frame in the call stack, if I want to catch a specific
exception, I can do that. Everything else goes up to the top-level
catch(...) and gets logged or converted to an error message as
appropriate.
>
Why should I arbitrarily restrict what exceptions I can throw in some
function?

>
You can throw whatever you want, on Earth 2, you just have to declare
what you throw, and force yourself to catch everything you throw, and
your C++ compiler will force you to do the right thing. Resistance is
futile. You will be caught.
>

It's like people are like "I'm disciplined with
return codes" and it's like "oh really, because
I'm pretty disciplined with return codes, and
if something's going to throw I put it in the
exception specification".
Then it's like people put a general exception
catcher that's not a general exception handler,
which usually results die, granularly,
and it's like "there's some things you
don't want to catch".
At least modeled exceptions establishing
behavior are like "yeah, you do want to
catch that, and as soon as possible".
It very complicates the type-system, or
the lambda-calculus, the exceptions, yet
also it makes it a quite thorough type-system.
Mostly it's an exercise in scope, and the
fact that there's so little discipline with
regards to whatever's accessible, it only
makes sense to make the compiler enforce it.
I'm a big fan of exceptions, it's a rule.