Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121358 > unrolled thread

Re: We have a new standard!

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-01 18:25 +0200
    Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-01 16:33 +0000
      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-01 09:41 -0800
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 08:06 +0100
        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-02 09:23 +0000
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 13:51 +0100
            Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 14:07 +0000
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:54 +0100
                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-02 17:15 +0000
                  Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:58 -0800
                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:13 +0000
                      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:22 -0800
                        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:17 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:31 +0100
                            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 11:34 +0000
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 14:01 +0100
                                Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 15:49 +0000
                      Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:42 -0800
                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-02 15:20 -0500
                  Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 13:43 +0100
                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 08:11 -0500
                      Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 16:33 +0200
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 10:50 -0500
                          Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 16:09 +0000
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:53 -0500
                              Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-03 17:10 +0000
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 12:14 -0500
                                  Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:13 +0000
                          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 18:17 +0100
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 13:58 -0500
                              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-04 12:39 +0100
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 09:56 -0500
                          Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-03 21:46 +0200
                            Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 21:06 -0500
                              Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 18:32 -0800
                              Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-04 20:08 +0200
                                Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-04 14:46 -0500
                                Re: We have a new standard! wij <wyniijj5@gmail.com> - 2025-01-05 07:14 +0800
                                Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-06 08:38 +0000
                                  Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-07 08:40 -0500
                                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-07 14:04 +0000
                                      Re: We have a new standard! Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-01-08 14:52 -0500
                                        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-08 13:31 -0800
                                        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-09 08:39 +0000
                                    Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-07 21:32 -0500
                        Re: We have a new standard! Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-01-03 17:49 -0800
                      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 17:12 +0100
                        Re: We have a new standard! Sam <sam@email-scan.com> - 2025-01-03 11:56 -0500
            Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 17:35 +0200
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 17:57 +0100
                Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 19:55 +0200
        Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:40 -0800
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-03 09:42 +0100
      Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-02 13:38 -0800
        Re: We have a new standard! Muttley@DastardlyHQ.org - 2025-01-03 10:09 +0000
          Re: We have a new standard! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-03 11:19 -0800
            Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-04 10:15 +0000
    Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-01 22:43 +0200
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2025-01-02 07:56 +0100
      Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-02 00:39 -0800
        Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 12:31 +0200
          Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 14:59 +0200
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-02 15:50 +0200
          Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-07 21:15 -0800
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-08 08:44 +0200
              Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-08 11:44 +0200
                Re: We have a new standard! James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-08 15:04 -0500
                Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 08:49 -0800
              Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-14 09:12 -0800
                Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2025-01-14 19:53 +0200
            Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-08 14:43 -0800
      Re: We have a new standard! scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:51 +0000
    Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-02 16:47 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#121389

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 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.

[toc] | [prev] | [next] | [standalone]

#121390

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)?

[toc] | [prev] | [next] | [standalone]

#121391

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?

>                                                                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.

> > 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)?

Not all exception classes, but all classes. But this has absolutely nothing  
to do, whatsoever, with validating that all exceptions will be caught by  
well-formed code.

Here's a free clue. Define "function X throws exception Y" if it throws that  
exception (and it doesn't catch it itself), or if it calls function Z that's  
declared (in Z's throw specifier) as throwing that exception. The compiler  
has all the information needed to know which exception can be thrown out of  
that function.

This is not C. This is C++. The compiler has the signature of every function  
called by code.

Then:

void throwing_function() throw(ExceptionClass)
{
}

… this function is allowed to throw ExceptionClass or any derived class. If  
it throws something else, it is ill-formed, and will refuse to compile.

void catching_function() // TBD
{
    throwing_function();
}

One of the following must be true for the catching_function(). Either:

1) The call to throwing function must be inside a try/catch that catches  
either ExceptionClass or any of its superclasses, which means that this  
exception gets caught and does not get propagated, and catching_function()  
can be declared noexcept. Or throw() for all that matters. Or, at some point  
in the bright future all functions without a throw specification will be  
treated as noexcept. Until then, something else will need to be done, but  
that's a separate discussion.

Or:

2) The catching function must be declared as throw(ExceptionClass), or as  
throwing any of its superclasses, thus propagating the exception, passing  
the hot potato to its callers.

With this, your suffering C++ compiler can now tell you that your C0D3Z are  
ill-formed, unless your code is logically guaranteed to catch every thrown  
exception. std::uncaught_exception() is deprecated.

The issue of overriding throwing_function() or catching_function() in a  
subclass is orthogonal, and can be resolved consistently with the same way  
analogous signature differences are resolved by C++'s current rules.

This is how exceptions are handled in Java, more or less, and /that's/ how  
throw specifications should've been handled in C++ from the begining,  
instead of that mess.

I'll go even as far as stating, that either:

A) I'm missing something obvious, something fundamental to C++ that would've  
prevented this implementation.

B) The original implementation of throw specifiers in C++ was written by  
(fill in your favorite perjorative here, mine is "morons").

[toc] | [prev] | [next] | [standalone]

#121392

On Fri, 03 Jan 2025 10:50:51 -0500
Sam <sam@email-scan.com> wibbled:
>Paavo Helde writes:
>Here's a free clue. Define "function X throws exception Y" if it throws that  
>exception (and it doesn't catch it itself), or if it calls function Z that's  
>declared (in Z's throw specifier) as throwing that exception. The compiler  
>has all the information needed to know which exception can be thrown out of  
>that function.
>
>This is not C. This is C++. The compiler has the signature of every function  
>called by code.

It needs more than that when function pointers are involved. It cannot
necessarily know at compile time which function will be assigned to the 
pointer so how is it supposed to know if the exception sig is valid? Unless 
you're suggesting also have an exception sig for function pointers which would 
probably break a whole load of code and make life difficult for zero gain.

[toc] | [prev] | [next] | [standalone]

#121394

Muttley@DastardlyHQ.org writes:

> On Fri, 03 Jan 2025 10:50:51 -0500
> Sam <sam@email-scan.com> wibbled:
> >Paavo Helde writes:
> >Here's a free clue. Define "function X throws exception Y" if it throws that
> >exception (and it doesn't catch it itself), or if it calls function Z that's
> >declared (in Z's throw specifier) as throwing that exception. The compiler
> >has all the information needed to know which exception can be thrown out of
> >that function.
> >
> >This is not C. This is C++. The compiler has the signature of every function
> >called by code.
>
> It needs more than that when function pointers are involved. It cannot

Do you happen to recall how a function pointer indicates that it's pointing  
to a noexcept function, by any chance?

Newflash: this already exists in C++. But instead of noexcept you put down  
the throw specification, and it works the same way.

> necessarily know at compile time which function will be assigned to the
> pointer so how is it supposed to know if the exception sig is valid?

The same way the compiler already prohibits you from assigning a pointer to  
a throwing function to a pointer to a noexcept function.

Am I the only one around here who doesn't see this as rocket science?

=========================================================================
int (*noexcept_func)() noexcept;

int (*except_func)();

void foo()
{
	except_func=noexcept_func; // OK
	noexcept_func=except_func; // Error
}
=========================================================================

A full throw specifier can also be validated for correctness, in the same  
exact FUCKING way, at compile time. This would look like…

=========================================================================
int (*noexcept_func)() throw(ExceptionA);

int (*except_func)() throw(ExceptionA, ExceptionB);

void foo()
{
	except_func=noexcept_func; // OK
	noexcept_func=except_func; // Error
}
=========================================================================

Sheesh, dark magic, isn't it?

(add a few more rules dealing how subclasses and superclasses are compared,  
in the throw specifier, for completeness)

> Unless
> you're suggesting also have an exception sig for function pointers which  
> would
> probably break a whole load of code and make life difficult for zero gain.

Not any more than existing code had to be rewritten when throw exceptions  
were removed leaving behind just noexcept.

For all that talk about not breaking existing code, it sure got broken many  
times, in C++'s history. If someone with a brain actually does a Picard, and  
makes it so, backwards compatibility won't be much of a concern.

[toc] | [prev] | [next] | [standalone]

#121396

On Fri, 03 Jan 2025 11:53:11 -0500
Sam <sam@email-scan.com> gabbled:
>A full throw specifier can also be validated for correctness, in the same  
>exact FUCKING way, at compile time. This would look like…

You seem to be getting very worked up about it. I don't know about java but
in C++ exceptions are just that - for exceptional circumstances. They're not
supposed to be used as glorified return statements so should be rarely used
anyway so frankly who gives a fuck about sigs?

[toc] | [prev] | [next] | [standalone]

#121397

Muttley@dastardlyhq.com writes:

> On Fri, 03 Jan 2025 11:53:11 -0500
> Sam <sam@email-scan.com> gabbled:
>> A full throw specifier can also be validated for correctness, in the same  
>> exact FUCKING way, at compile time. This would look like…
>
> You seem to be getting very worked up about it. I don't know about java but
> in C++ exceptions are just that - for exceptional circumstances. They're not
> supposed to be used as glorified return statements so should be rarely used
> anyway so frankly who gives a fuck about sigs?

You convinced me. Let's just get rid of function signatures entirely. It's  
time to get to basics, the K&R way.

[toc] | [prev] | [next] | [standalone]

#121407

On Fri, 03 Jan 2025 12:14:00 -0500
Sam <sam@email-scan.com> gabbled:
>Muttley@dastardlyhq.com writes:
>
>> On Fri, 03 Jan 2025 11:53:11 -0500
>> Sam <sam@email-scan.com> gabbled:
>>> A full throw specifier can also be validated for correctness, in the same  
>>> exact FUCKING way, at compile time. This would look like…
>>
>> You seem to be getting very worked up about it. I don't know about java but
>> in C++ exceptions are just that - for exceptional circumstances. They're not
>> supposed to be used as glorified return statements so should be rarely used
>> anyway so frankly who gives a fuck about sigs?
>
>You convinced me. Let's just get rid of function signatures entirely. It's  
>time to get to basics, the K&R way.

Parameter types are a *teensy* bit more important.

[toc] | [prev] | [next] | [standalone]

#121398

On 03/01/2025 16:50, Sam wrote:

> I'll go even as far as stating, that either:
> 
> A) I'm missing something obvious, something fundamental to C++ that 
> would've prevented this implementation.
> 
> B) The original implementation of throw specifiers in C++ was written by 
> (fill in your favorite perjorative here, mine is "morons").
> 

The answer is obviously A.

Be a little less obnoxious in your posts, and maybe someone will explain 
it to you (if you are unable to understand the posts I've already made).

[toc] | [prev] | [next] | [standalone]

#121399

David Brown writes:

> On 03/01/2025 16:50, Sam wrote:
>
>> I'll go even as far as stating, that either:
>>
>> A) I'm missing something obvious, something fundamental to C++ that would've  
>> prevented this implementation.
>>
>> B) The original implementation of throw specifiers in C++ was written by  
>> (fill in your favorite perjorative here, mine is "morons").
>>
>
> The answer is obviously A.

Maybe to a super-genius like yourself, but mere mortals may have some  
trouble figuring it out.

> Be a little less obnoxious in your posts, and maybe someone will explain it  
> to you (if you are unable to understand the posts I've already made).

Sir: this is Usenet, and not Facebook. Go down the hall, last door on your  
left.

[toc] | [prev] | [next] | [standalone]

#121412

On 03/01/2025 19:58, Sam wrote:
> David Brown writes:
> 
>> On 03/01/2025 16:50, Sam wrote:
>>
>>> I'll go even as far as stating, that either:
>>>
>>> A) I'm missing something obvious, something fundamental to C++ that 
>>> would've prevented this implementation.
>>>
>>> B) The original implementation of throw specifiers in C++ was written 
>>> by (fill in your favorite perjorative here, mine is "morons").
>>>
>>
>> The answer is obviously A.
> 
> Maybe to a super-genius like yourself, but mere mortals may have some 
> trouble figuring it out.
> 

Right.  The super-geniuses - like Stroustrup and his colleagues - 
understood what they were doing.  They understood that any language 
design decision is a compromise, and picked the balance that they 
believed worked best for the kind of language they were creating.  Then 
40-odd years later some mere mortal comes along and says they were all 
morons.

I don't need to be a super-genius to see that the answer is obviously A.

>> Be a little less obnoxious in your posts, and maybe someone will 
>> explain it to you (if you are unable to understand the posts I've 
>> already made).
> 
> Sir: this is Usenet, and not Facebook. Go down the hall, last door on 
> your left.
> 

I can't stop you being obnoxious in your posts.  But I /can/ tell you it 
greatly reduces your chances of getting helpful answers to your posts.

[toc] | [prev] | [next] | [standalone]

#121414

David Brown writes:

> On 03/01/2025 19:58, Sam wrote:
>> David Brown writes:
>>
>>> On 03/01/2025 16:50, Sam wrote:
>>>
>>>> I'll go even as far as stating, that either:
>>>>
>>>> A) I'm missing something obvious, something fundamental to C++ that would've  
>>>> prevented this implementation.
>>>>
>>>> B) The original implementation of throw specifiers in C++ was written by  
>>>> (fill in your favorite perjorative here, mine is "morons").
>>>>
>>>
>>> The answer is obviously A.
>>
>> Maybe to a super-genius like yourself, but mere mortals may have some  
>> trouble figuring it out.
>>
>
> Right.  The super-geniuses - like Stroustrup and his colleagues - understood  
> what they were doing.  They understood that any language design decision is  
> a compromise, and picked the balance that they believed worked best for the  
> kind of language they were creating.  Then 40-odd years later some mere  
> mortal comes along and says they were all morons.
>
> I don't need to be a super-genius to see that the answer is obviously A.

In that case, we have a Scooby-Doo mystery on our hands. Despite this claim,  
not a single super-genius has ever been able to articulate any technical  
reason that prevents exception handling validation.

Go ahead. Explain why a C++ compiler can handle noexcept-correctness, but  
will not be able to handle full exception signature/catching enforcement.

You can't. No amount of bloviating will change that. You can prove me wrong  
simply by showing why it's not possible. You won't. All you'll do is claim  
that only super-geniuses understand why. Go ahead, there's the sandbox, with  
inflatable toys, for all the super-geniuses to play with. You can play there  
for the rest of the day.

>>> Be a little less obnoxious in your posts, and maybe someone will explain it  
>>> to you (if you are unable to understand the posts I've already made).
>>
>> Sir: this is Usenet, and not Facebook. Go down the hall, last door on your  
>> left.
>>
>
> I can't stop you being obnoxious in your posts.  But I /can/ tell you it  
> greatly reduces your chances of getting helpful answers to your posts.

How much does it cost, in electricity, that magical mind ray-beam machine of  
yours?

[toc] | [prev] | [next] | [standalone]

#121402

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(). 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.

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.

>>                                                                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? The goal is to compile my 
code, not to get compiler errors.

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). 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?

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? Seems to me like arbitrarily deciding that some functions may 
not use switch() and some other functions may not use while(). Why?

[toc] | [prev] | [next] | [standalone]

#121405

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.

[toc] | [prev] | [next] | [standalone]

#121406

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.

[toc] | [prev] | [next] | [standalone]

#121416

On 04.01.2025 04:06, Sam wrote:
> Paavo Helde writes:
> 
>>
>> 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 an exception has reached the top-level catch, then this means that 
all lower levels (which have more knowledge about the context) have not 
been able to catch and handle it. In the top-level catch there is little 
hope I could do anything smarter, typically I just need to report or log 
an error message.

So there is no need to differentiate between different types of 
exceptions or to extract any useful bits from them, all I need is an 
error message. For that I have a little helper function which can be 
called from inside catch(...) and which handles various exception base 
classes and falls back to typeid(e).name() for unknown types. Actually I 
am not interested in exception types at all at this point, not to speak 
about enforcing them somehow. If there appear new exception base 
classes, I add support for them in the helper function, not trying to 
reduce their usage.

[...]

> 
> 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)

That's the first good idea from you in this discussion. I still do not 
see much point in exception specifications, but such a typedef would at 
least make life easier for me on this Alternate Earth.

PS. Nowadays they prefer `using` instead of `typedef`.

[toc] | [prev] | [next] | [standalone]

#121418

Paavo Helde writes:

> On 04.01.2025 04:06, Sam wrote:
>> Paavo Helde writes:
>>
>>>
>>> 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 an exception has reached the top-level catch, then this means that all  
> lower levels (which have more knowledge about the context) have not been  
> able to catch and handle it. In the top-level catch there is little hope I  
> could do anything smarter, typically I just need to report or log an error  
> message.
>
> So there is no need to differentiate between different types of exceptions  
> or to extract any useful bits from them, all I need is an error message. For  
> that I have a little helper function which can be called from inside  
> catch(...) and which handles various exception base classes and falls back  
> to typeid(e).name() for unknown types. Actually I am not interested in  
> exception types at all at this point, not to speak about enforcing them  
> somehow. If there appear new exception base classes, I add support for them  
> in the helper function, not trying to reduce their usage.

Certainly: many uses cases that involve exceptions are satisfied by having  
exception convey nothing more than a plain, textual, error message.

Evolution of exception handling usually begins with this situation. Then,  
natural code evolution ropes in the need to actually discriminate and  
identify specific exception situations. The first instances of exception  
throwing discrete classes pop up. They multiply, and then, inevitably,  
arises a situation that involves a failure to implement a new exception  
class, because the current iteration of C++ fails to detect uncaught  
exceptions at compile time. And here we are.

> [...]
>
>>
>> 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)
>
> That's the first good idea from you in this discussion. I still do not see  
> much point in exception specifications, but such a typedef would at least  
> make life easier for me on this Alternate Earth.
>
> PS. Nowadays they prefer `using` instead of `typedef`.

So, after adding things up on the abacus, this becomes

using AlgoThrownClasses = throws(ClassA, ClassB);

[toc] | [prev] | [next] | [standalone]

#121419

On Sat, 2025-01-04 at 20:08 +0200, Paavo Helde wrote:
> On 04.01.2025 04:06, Sam wrote:
> > Paavo Helde writes:
> > 
> > > 
> > > 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 an exception has reached the top-level catch, then this means that 
> all lower levels (which have more knowledge about the context) have not 
> been able to catch and handle it. In the top-level catch there is little 
> hope I could do anything smarter, typically I just need to report or log 
> an error message.
> 
> So there is no need to differentiate between different types of 
> exceptions or to extract any useful bits from them, all I need is an 
> error message. For that I have a little helper function which can be 
> called from inside catch(...) and which handles various exception base 
> classes and falls back to typeid(e).name() for unknown types. Actually I 
> am not interested in exception types at all at this point, not to speak 
> about enforcing them somehow. If there appear new exception base 
> classes, I add support for them in the helper function, not trying to 
> reduce their usage.

This is an interrupt, I didn't read the context of this thread.

std::except was a big blunder (not invented by B.S.). It is similar to 
errno or a global object, you set it up and throw. C++ hide it in a 
beautiful theory called 'advanced error handling'.... long story.

> [...]
> 
> > 
> > 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)
> 
> That's the first good idea from you in this discussion. I still do not 
> see much point in exception specifications, but such a typedef would at 
> least make life easier for me on this Alternate Earth.
> 
> PS. Nowadays they prefer `using` instead of `typedef`.
> 
> 

[toc] | [prev] | [next] | [standalone]

#121420

On Sat, 4 Jan 2025 20:08:00 +0200
Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>On 04.01.2025 04:06, Sam wrote:
>> void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>
>That's the first good idea from you in this discussion. I still do not 
>see much point in exception specifications, but such a typedef would at 
>least make life easier for me on this Alternate Earth.
>
>PS. Nowadays they prefer `using` instead of `typedef`.

I never understood the point of that. Why not increase the semantic scope
of "typedef" instead of having 2 keywords that in a lot of circumstances
do the same thing?

[toc] | [prev] | [next] | [standalone]

#121421

Muttley@DastardlyHQ.org wrote this post while blinking in Morse code:

> On Sat, 4 Jan 2025 20:08:00 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wibbled:
>>On 04.01.2025 04:06, Sam wrote:
>>> void my_algorithm(algorithm_info_t &) throws(AlgoThrownClasses)
>>
>>That's the first good idea from you in this discussion. I still do not 
>>see much point in exception specifications, but such a typedef would at 
>>least make life easier for me on this Alternate Earth.
>>
>>PS. Nowadays they prefer `using` instead of `typedef`.
>
> I never understood the point of that. Why not increase the semantic scope
> of "typedef" instead of having 2 keywords that in a lot of circumstances
> do the same thing?

Because using is a nicer to read?

-- 
A new supply of round tuits has arrived and are available from Mary.
Anyone who has been putting off work until they got a round tuit now
has no excuse for further procrastination.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web