On Sun, May 29, 2022 at 5:56 PM Peter Dimov via Boost
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
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
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
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
operations. that their the 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.