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.