Date: Sat, 29 Aug 2026 10:38:35 -0300
On Saturday, 29 August 2026 09:15:53 Brasilia Standard Time Yongwei Wu via
Std-Proposals wrote:
> C++ exception classes normally form a hierarchy, and catching the reference
> of any node will catch all errors in the sub-tree. This is exactly an
> advantage of exceptions.
>
> People giving the comment above should be banned from reviewing C++ code.
And the even more C++ thing is that you choose what to use and what not to
use.
The problem of catching a vaguer (base) class at an outer point is that the
exception has no meaning there. For example, if as a result of a user input,
the code needs to open some file and cannot or it's corrupt, so it throws (real
world scenario: you've got a bug report from a user that deployed ICU with a
separate data file instead of a library and can therefore returned
U_FILE_ACCESS_ERROR where you didn't expect). The next level of code was never
prepared to catch this new exception, so it lets it through.
Four or five levels deeper, there's a catch (std::exception): what is it to do?
My argument is there's nothing it can do to save the application. The most it
can do is an emergency save and restart. And even then you have to be
extremely careful, because attempting to do anything when your program state
is inconsistent can lead to further corruption.
At that point, my argument is that you should *not* catch at all. Just let the
exception unwind mechanism crash the application. That way, you get the best
post-mortem debugging information, uncorrupted by the attempt to unwind the
stack and save things in an emergency. If you were keeping state files, your
next application's start will reload them, without the need for an emergency
save. All you need is a crash-watchdog to restart your application, which is a
known problem with known solutions.
I am not saying you shouldn't use exceptions or catch the ones thrown. That's
a choice and I'll leave everyone to theirs. My argument is that overly-broad
catching is detrimental, therefore it's not an answer to "code needs to throw
new exceptions". If you need to catch, either catch at the most local point
where the context is still meaningful or don't catch at all. And if you choose
the former, then you may need to adapt that code with a new exception thrown,
which cascades to the next level.
Std-Proposals wrote:
> C++ exception classes normally form a hierarchy, and catching the reference
> of any node will catch all errors in the sub-tree. This is exactly an
> advantage of exceptions.
>
> People giving the comment above should be banned from reviewing C++ code.
And the even more C++ thing is that you choose what to use and what not to
use.
The problem of catching a vaguer (base) class at an outer point is that the
exception has no meaning there. For example, if as a result of a user input,
the code needs to open some file and cannot or it's corrupt, so it throws (real
world scenario: you've got a bug report from a user that deployed ICU with a
separate data file instead of a library and can therefore returned
U_FILE_ACCESS_ERROR where you didn't expect). The next level of code was never
prepared to catch this new exception, so it lets it through.
Four or five levels deeper, there's a catch (std::exception): what is it to do?
My argument is there's nothing it can do to save the application. The most it
can do is an emergency save and restart. And even then you have to be
extremely careful, because attempting to do anything when your program state
is inconsistent can lead to further corruption.
At that point, my argument is that you should *not* catch at all. Just let the
exception unwind mechanism crash the application. That way, you get the best
post-mortem debugging information, uncorrupted by the attempt to unwind the
stack and save things in an emergency. If you were keeping state files, your
next application's start will reload them, without the need for an emergency
save. All you need is a crash-watchdog to restart your application, which is a
known problem with known solutions.
I am not saying you shouldn't use exceptions or catch the ones thrown. That's
a choice and I'll leave everyone to theirs. My argument is that overly-broad
catching is detrimental, therefore it's not an answer to "code needs to throw
new exceptions". If you need to catch, either catch at the most local point
where the context is still meaningful or don't catch at all. And if you choose
the former, then you may need to adapt that code with a new exception thrown,
which cascades to the next level.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-08-29 13:38:49
