Date: Sun, 30 Aug 2026 11:00:15 +0800
On Sun, 30 Aug 2026 at 03:47, Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I have the exact same gripe, but with exceptions instead. People just
> throw exceptions, and don't handle them, expecting that it be magically
> handled somewhere else. While with error code you are forced to deal with
> the problem locally where you are for more likely to have context in what
> it is that you were trying to do and what is the best course of action to
> do instead.
>
I have seen enough code that calls a function, then checks whether the
error code equals SUCCESS, and continues only if it is (returning the error
code otherwise).
The error is not handled locally. Error code definition can be a complete
mess when there are multiple modules developed by different
organizations/departments. (std::error_code can help, but it is not used in
the projects I just mentioned.)
Tracing the source of such errors is harder than exceptions. If exceptions
are used, I just need to find a failure case and not catch intentionally.
Then GDB will help me identify the source of the problem.
And there are no detailed log messages to record in the case of such error
codes. The int code is all you get.
> If you have people just casting the return value just to not deal with it,
> I mean that just negligence from the part of the developer at that point.
> You did your best to warn people of the problem, and they have to get
> creative to do something to ignore it.
> The same way you can't force people to catch your exception, except you
> can see it when you cast the return code away.
>
> I would write that down to there are a lot of developers out there that
> probably should have considered a different line of work and don't handle
> errors period.
> Seems cliché to blame it on a skill issue, but at some point it is. We
> should aim the feature for professionals, i.e. if you do your best to do
> things right you should be rewarded with having a functional language as
> opposed tailoring the language for amateurs and then no matter how good you
> are things will never be good because the language was broken for the sake
> of "simplicity".
std-proposals_at_[hidden]> wrote:
> I have the exact same gripe, but with exceptions instead. People just
> throw exceptions, and don't handle them, expecting that it be magically
> handled somewhere else. While with error code you are forced to deal with
> the problem locally where you are for more likely to have context in what
> it is that you were trying to do and what is the best course of action to
> do instead.
>
I have seen enough code that calls a function, then checks whether the
error code equals SUCCESS, and continues only if it is (returning the error
code otherwise).
The error is not handled locally. Error code definition can be a complete
mess when there are multiple modules developed by different
organizations/departments. (std::error_code can help, but it is not used in
the projects I just mentioned.)
Tracing the source of such errors is harder than exceptions. If exceptions
are used, I just need to find a failure case and not catch intentionally.
Then GDB will help me identify the source of the problem.
And there are no detailed log messages to record in the case of such error
codes. The int code is all you get.
> If you have people just casting the return value just to not deal with it,
> I mean that just negligence from the part of the developer at that point.
> You did your best to warn people of the problem, and they have to get
> creative to do something to ignore it.
> The same way you can't force people to catch your exception, except you
> can see it when you cast the return code away.
>
> I would write that down to there are a lot of developers out there that
> probably should have considered a different line of work and don't handle
> errors period.
> Seems cliché to blame it on a skill issue, but at some point it is. We
> should aim the feature for professionals, i.e. if you do your best to do
> things right you should be rewarded with having a functional language as
> opposed tailoring the language for amateurs and then no matter how good you
> are things will never be good because the language was broken for the sake
> of "simplicity".
Received on 2026-08-30 03:00:35