On Sat, 29 Aug 2026 at 21:38, Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

There are different ways that exceptions can be used. And exceptions
do not rule out the use of error codes.

If the app is a command-line app, I agree that letting the program
crash is a good idea. However, thinking about the scenario of a server
app which handles thousands (if not more) of connections at the same
time. It cannot easily crash because of one error, even though it is
serious.

If the error can be predicted, using an error code and processing the
error locally could be a good idea.

If a serious error occurred, which is not a normally anticipated case,
throwing an exception is probably good. An outer function that deals
with a specific request can catch the exception and return an error to
the requestor, something like an HTTP 500 error. A log message can be
recorded so that an admin can check the error later.

So while I appreciate the spirit of not catching in a remote place, I
do not agree with your conclusion.