# Is checking return values always required? [duplicate]

We know that checking return values prevent our software from unexpected states. (You can see CWE definition.) But, we are sometimes sure about the return value. For example:

``````bool calculateSquareRootReturnFalseIfInputIsNegative(float input, float& output);
float calculateHypotenuse(float a, float b){
float c2 = (a*a) + (b*b);
float c;
calculateSquareRootReturnFalseIfInputIsNegative(c2, c);
return c;
}
``````

The local variable `c2` is always positive. So, `calculateSquareRootReturnFalseIfInputIsNegative()` always returns true. I shouldn't check its return value.

Finally, Is "check all return values not already known by caller" a valid idiom?

Thanks..

• ...in this code snippet, `a*a` can overflow
– gnat
Dec 24, 2014 at 15:25
• @gnat But since we're dealing with floats, not with integers, the overflow will "only" result in infinity, not in wrap-around to negative quantities.
– user7043
Dec 24, 2014 at 15:29
• @delnan of course. Thing is, this doesn't necessarily qualify as being "sure about the return value"
– gnat
Dec 24, 2014 at 15:35
• Check them, for Pete's sake. Dec 25, 2014 at 2:42
• @delnan: Optimizer optimizes on the basis of no signed overflow anyway, since it is UB. Dec 25, 2014 at 10:42

Is checking return values always required?

I don't think so; rather, they are almost always required. Proper error checking is very important, although sometimes it can admittedly be a pain in the neck.

However, your particular example does not describe a typical "perform operation that may fail and check the error" scenario. If your assumption about the sum of squares being positive is right (e. g. you expect this to be the case, and you don't permit e. g. `NaN` inputs), then what you are looking for is an assertion.

Assertions are used in situations exactly like this: when you have an operation that can sometimes fail, but you always pass it inputs for which it cannot possibly/shouldn't ever fail. Your program's internal consistency depends on this, so you assert, so that if this promise/assumption in your code ever breaks, you will get notified (i. e. the program crashes reliably at the earliest point it detects the inconsistency).

That depends upon what you mean. If you mean is it required in order to output the correct result, the answer is no. If you mean is it required in order for the code to be well written, then the answer is yes.

Well written code is code that is unambiguous to the reader -- if I read your code and see you ignore a return value, I have to break out my psychic abilities and determine if you INTENTIONALLY or INADVERTANTLY ignored the return value in order to understand what you meant the code to do. My psychic abilities are notorious for returning ambiguous results.

More seriously, an empty if block (with or without a comment) makes it clear that you know about the return value (and that it wasn't for instance added as part of a refactoring) and that you considered what to do. It also provides a handy starting point to add the code to handle the return value if it turns out that it needs to be handled after all.

No. There is nothing idiomatic about error-handling-by-return-value, either in the callee side or the caller. Leave these terrible practices in the Stone Age where they belong.

You should write your functions to throw on failure. If you're using a library that hasn't been updated since 1972, then you need to wrap it to provide a usable interface.

• Throw what exactly? Exception? Some people believe exceptions are evil. Dec 25, 2014 at 12:18
• If the `calculateSquareRootReturnFalseIfInputIsNegative()` function was defined as `calculateSquareRootThrowIfInputIsNegative()`, the problem would still be valid: Shall I encapsulate the function call with an empty try-catch block -it guarantees no-throw safety for `calculateHypotenuse()` function-, or shall I consider `calculateHypotenuse()` as a function can throw something?
– Q Q
Dec 25, 2014 at 12:27
• @53777A: Those people are wrong and it's as simple as that. Unless you have some quite niche hardware restrictions. Dec 25, 2014 at 18:10
• @QQ: Just declare it as noexcept. You don't need to add an empty try-catch. Dec 25, 2014 at 18:10
• How would you return an exception in C? May 26, 2022 at 19:43