Date: Tue, 1 Sep 2026 07:10:19 +0200
> On Sep 1, 2026, at 1:50 AM, Jonathan Grant via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On 28/08/2026 17:33, Tiago Freire via Std-Proposals wrote:
>>> the real problem is as soon as you make that change you have often thousands of functions that cascading need to change because now you changed your interface.
>>
>> Yes, but isn't that just the symptom of a much larger problem.
>> You haven't as much provided a useful function as you have provided a means for your application to ungracefully terminate if you don't document that your code can throw, what it can throw and how you can recover if a function does throw. I.e. you just gave everyone a loaded foot gun.
>>
>> If you state that your function can throw A, B, and C I can write a catch clause to catch A, B, and C and *handle the error*.
>> But now you if you make a change and it can also throw D, the fact that this cascades trough out your entire code base is a good thing.
>> You have changed the contract of what the function can do, code that was previously safe now isn't, and if the caller doesn't catch it you have also changed the caller's contract, then the caller of the caller will throw an additional exception as well.
>>
>> Exceptions are evil because it changes code upstream instead of downstream.
>
> Are these exceptions still derived from std::exception?
> If a sub-system has a failure, and std::exception is caught, it will catch them.
>
> ie subsystem has a new failure mode, but the software was designed for std::out_of_range but std::logic_error is thrown, it would still be caught. Often in these cases it is logged, and the application may, or may not retry the action. It would be better to try and verify at compile-time.
Your comments led me to yet another thought. If we start annotating functions with exceptions, would I have to annotate the exact types of the exceptions or could I use a base type? I would consider it best practice if the exact type is used for the function that throws the exception. But, once the exception travels up the call stack, I might want to write down a base class of the exception instead.
>
>
>
> On 28/08/2026 17:33, Tiago Freire via Std-Proposals wrote:
>>> the real problem is as soon as you make that change you have often thousands of functions that cascading need to change because now you changed your interface.
>>
>> Yes, but isn't that just the symptom of a much larger problem.
>> You haven't as much provided a useful function as you have provided a means for your application to ungracefully terminate if you don't document that your code can throw, what it can throw and how you can recover if a function does throw. I.e. you just gave everyone a loaded foot gun.
>>
>> If you state that your function can throw A, B, and C I can write a catch clause to catch A, B, and C and *handle the error*.
>> But now you if you make a change and it can also throw D, the fact that this cascades trough out your entire code base is a good thing.
>> You have changed the contract of what the function can do, code that was previously safe now isn't, and if the caller doesn't catch it you have also changed the caller's contract, then the caller of the caller will throw an additional exception as well.
>>
>> Exceptions are evil because it changes code upstream instead of downstream.
>
> Are these exceptions still derived from std::exception?
> If a sub-system has a failure, and std::exception is caught, it will catch them.
>
> ie subsystem has a new failure mode, but the software was designed for std::out_of_range but std::logic_error is thrown, it would still be caught. Often in these cases it is logged, and the application may, or may not retry the action. It would be better to try and verify at compile-time.
Your comments led me to yet another thought. If we start annotating functions with exceptions, would I have to annotate the exact types of the exceptions or could I use a base type? I would consider it best practice if the exact type is used for the function that throws the exception. But, once the exception travels up the call stack, I might want to write down a base class of the exception instead.
Received on 2026-09-01 05:10:38