Re: exception handling anti-patterns in documentation

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2022-05-30 01:06:36

On Sun, May 29, 2022 at 5:56 PM Peter Dimov via Boost <boost_at_[hidden]>
wrote:
>
> 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

It is legitimate only in the sense that it is valid to throw an exception
when the preconditions for calling a function aren't met (just as it would
be valid to do other things, like assert or outright abort). It's a bug, we
shouldn't be trying to recover a buggy program by catching exceptions.