One can mix the error abstracts, we have to anyways(cmath methods and NaN). When the distance between the error and the caller that can act on the error is lar

One can mix the error abstracts, we have to anyways(cmath methods and NaN). When the distance between the error and the caller that can act on the error is large, it makes much more sense to throw in a large number of cases. Otherwise the cost is code that would have been error neutral becoming error opinionated and that is a software engineering cost. But look at some of the costs we have to go to great lengths to get around. std::sqrt has to check for invalid inputs and that means a branch, often even when the code is checked prior or an ASSUME( f > 0.0 ) type thing is expressed. This inhibits auto-vectorization. On some compilers ASSUME( not std::isless( f, 0.0 ) ) can tell the compile that the number is real and >= 0 which elides the branch. But the math-error/errno issue is a big hinderance too. A lot of the costs is the branch itself and telling the compiler it is not needed can boost hot path perf more than the rare cold paths.