PS. And it is not like I’m just passing wind here.

You are talking with someone who has an experience on these things.

Making this sort of comments on PR has stopped errors from making it into production.

And the fact that we do ask those questions is a lesson that was learned the hard way.

Having such an extreme reaction to it means that you had a different experience and never had to deal with these problems.

From: Yongwei Wu <wuyongwei@gmail.com>
Sent: Saturday, August 29, 2026 14:16
To: std-proposals@lists.isocpp.org
Cc: marcinjaczewski86@gmail.com; Tiago Freire <tmiguelf@hotmail.com>
Subject: Re: [std-proposals] fine-control exception/error/UB handling on function boundary

On Sat, 29 Aug 2026 at 16:42, Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> 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

E.14: Use purpose-designed user-defined types as exceptions (not built-in types)

E.15: Throw by value, catch exceptions from a hierarchy by reference