> One of the ideas of exceptions is that not all intermediate functions have to list (or even know) all exceptions, which can happen. Whether that idea has merit or whether it is a bad idea is a different question, but one would have to answer it first before annotating all thrown exceptions.

I don't see that as a weakness of the proposition but rather a symptom of the complexity of the problem that it tries to solve.

Exceptions must be handled or otherwise your application is forced to terminate. If you don't want that you must handle the exception, but how could you handle IT if you don't know what IT is?

And if your list ends up extremely long, isn't that a sign that perhaps it's a bigger problem that you have been ignoring? Throwing an exception is a debt in behavior, it must be paid somewhere.




________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Saturday, May 10, 2025 1:20:21 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] noexcept has gotten a bit hairy -- I want a compiler error


One of the ideas of exceptions is that not all intermediate functions have to list (or even know) all exceptions, which can happen.

Whether that idea has merit or whether it is a bad idea is a different question, but one would have to answer it first before annotating all thrown exceptions.



As a food for thought:



One probably has a "hierarchical" relationship of which exceptions can happen:



All functions in my component may throw, if memory low.

The database functions may throw, if there is a database error.

The file functions may throw, if disk full or not reachable or there is an access permission error.



One can narrow it down further for specific functions.

If you start to annotate, you probably want some convenience.



Could e.g. either be by exception inheritance, by (exception type) constraints, by member function/class inheritance, by hierarchical namespace or by something else?


-----Ursprüngliche Nachricht-----
Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Sa 10.05.2025 13:11
Betreff: Re: [std-proposals] noexcept has gotten a bit hairy -- I want a compiler error
An: std-proposals_at_[hidden];
CC: Tiago Freire <tmiguelf_at_[hidden]>;
If you want to do something with exceptions, I think it's far more productive to annotate what type of exceptions a function can throw as opposed to that it can just throw exceptions. And make not throwing exceptions the default.

Exceptions are a fundamentally broken concept and since their inception the same problems keep popping up.
Adding features to exception feels like a waste of time, like putting lipstick on a pig.

If you want to fix something we need to address the basic concepts that it got wrong.

Other modern language that decided not to have exceptions are safer because of it, and it was the best design choice they could have made.

My 2c is kill it.