Date: Sat, 29 Aug 2026 20:15:53 +0800
On Sat, 29 Aug 2026 at 16:42, Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> This is exactly the trap I've seen in production code over and over again.
>
> From my experience code that uses exceptions is more unstable
> (unexpectedly crashes), and 9 times out of 10 the reason for that
> instability is unhandled exceptions.
> You throw a new exception and you think you don't have to care, and that
> it somehow it all gets solved by magic. But somewhere up the call stack
> someone has to, and it is really hard to find out where that is.
> Every time you throw a new type of exception you incur a debt that has to
> be paid.
>
> You can always argue "I don't have to care here, I don't have to care
> there" and you can squint your eyes and say "yeah...ok", but then make the
> mistake of thinking that you "don't have to care anywhere".
> That's how bugs of this sort often get introduced. This is precisely the
> kind of thing that should pop up in a code review and get the comment "hey
> can you not introduce a new exception and just use std::exception [like
> always]?"
This is a very un-C++ comment.
1. std::exception is designed to be a base class. It does not have a
constructor that accepts an error message to make what() useful.
2. One normally derives the exception class from a derived class of
std::exception, most likely std::runtime_error or std::logic_error. Then,
in main or somewhere close, there is a `catch (const std::exception& e)` or
`catch (const std::runtime_error&)` (i.e. let logic_error and other design
bugs blow off the program).
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.
> or "have you validated that all code upstream is prepared to receive this
> exception?"
As long as main() or somewhere close catches the exception, this is not a
problem. In general, code between the catch-all point and the throwing
point is only required to be exception-safe, and handles exceptions only if
it can handle better than main(). The comment is actually quite meaningless.
Relevant C++ Core Guidelines:
E.2: Throw an exception to signal that a function can’t perform its
assigned task
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-throw>
E.14: Use purpose-designed user-defined types as exceptions (not built-in
types)
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-exception-types>
E.15: Throw by value, catch exceptions from a hierarchy by reference
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-exception-ref>
std-proposals_at_[hidden]> wrote:
> This is exactly the trap I've seen in production code over and over again.
>
> From my experience code that uses exceptions is more unstable
> (unexpectedly crashes), and 9 times out of 10 the reason for that
> instability is unhandled exceptions.
> You throw a new exception and you think you don't have to care, and that
> it somehow it all gets solved by magic. But somewhere up the call stack
> someone has to, and it is really hard to find out where that is.
> Every time you throw a new type of exception you incur a debt that has to
> be paid.
>
> You can always argue "I don't have to care here, I don't have to care
> there" and you can squint your eyes and say "yeah...ok", but then make the
> mistake of thinking that you "don't have to care anywhere".
> That's how bugs of this sort often get introduced. This is precisely the
> kind of thing that should pop up in a code review and get the comment "hey
> can you not introduce a new exception and just use std::exception [like
> always]?"
This is a very un-C++ comment.
1. std::exception is designed to be a base class. It does not have a
constructor that accepts an error message to make what() useful.
2. One normally derives the exception class from a derived class of
std::exception, most likely std::runtime_error or std::logic_error. Then,
in main or somewhere close, there is a `catch (const std::exception& e)` or
`catch (const std::runtime_error&)` (i.e. let logic_error and other design
bugs blow off the program).
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.
> or "have you validated that all code upstream is prepared to receive this
> exception?"
As long as main() or somewhere close catches the exception, this is not a
problem. In general, code between the catch-all point and the throwing
point is only required to be exception-safe, and handles exceptions only if
it can handle better than main(). The comment is actually quite meaningless.
Relevant C++ Core Guidelines:
E.2: Throw an exception to signal that a function can’t perform its
assigned task
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-throw>
E.14: Use purpose-designed user-defined types as exceptions (not built-in
types)
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-exception-types>
E.15: Throw by value, catch exceptions from a hierarchy by reference
<https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#re-exception-ref>
Received on 2026-08-29 12:16:13
