Re: exception handling anti-patterns in documentation

From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-05-30 00:55:57

Gavin Lambert wrote:
> On 30/05/2022 11:59, Emil Dotchevski wrote:
> > The correct use of exception handling in C++ is to let exceptions
> > propagate unmolested by default; there is no explicit checking for
> > errors after calling a function that may throw. You catch only where
> > the error can be handled and the program can restore normal operations.
> 
> The problem with this definition is that it is too vague (although that is
> somewhat of necessity due to being general advice).
> 
> Someone can, by the letter (but not the spirit) of that rule, argue that their
> program can resume normal operations immediately outside of that function
> call (to e.g. handle a "file not found" or a "input string was not a number" type
> of error that really ought to be checked a different way).

Someone can, but it would be hard if lib::function also supplies a nonthrowing
overload. It makes absolutely no sense to prefer the throwing overload if the
exception is handled immediately, as in the example given.

> The argument for the "truly exceptional" case is that since exceptions should
> never normally happen,

This sort of programs use exceptions to detect logic errors, e.g. vector::at even
if the index is known to be in range. That's kind of legitimate, if not particularly
appealing, but I suspect the documentation examples we're discussing here
don't fall into this category. We're probably talking more about json::value::at,
where the value comes from external input, and exceptions happening is a
totally normal occurrence.