3

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 '14 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 '14 at 15:29
  • 1
    @delnan of course. Thing is, this doesn't necessarily qualify as being "sure about the return value" – gnat Dec 24 '14 at 15:35
  • Check them, for Pete's sake. – Tulains Córdova Dec 25 '14 at 2:42
  • @delnan: Optimizer optimizes on the basis of no signed overflow anyway, since it is UB. – DeadMG Dec 25 '14 at 10:42
1

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).

0

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.

0

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.

  • 1
    Throw what exactly? Exception? Some people believe exceptions are evil. – 53777A Dec 25 '14 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 '14 at 12:27
  • @53777A: Those people are wrong and it's as simple as that. Unless you have some quite niche hardware restrictions. – DeadMG Dec 25 '14 at 18:10
  • @QQ: Just declare it as noexcept. You don't need to add an empty try-catch. – DeadMG Dec 25 '14 at 18:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.