Yes. It's locality of behavior.

That's the nature of software development, you want to doSomething() but doSomething() is often { broken(); down(); into(); smaller(); tasks(); }.
Exceptions often happen in the details, if the small() functions don't know how to deal with it, the bigger() function for which small() is just a tiny detail will also likely not know how to deal with it.
And the higher up the stack you go, the less likely it is that the problem will be solved and the more likely the solution is "well I guess I can't just do that thing...abort" (not to be confused with std::abort()).


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Saturday, August 29, 2026 15:39
To: std-proposals_at_lists.isocpp.org
Cc: Thiago Macieira <thiago_at_macieira.org>
Subject: Re: [std-proposals] fine-control exception/error/UB handling on function boundary

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
> C++ 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.