Re: We have a new standard!

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