Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Should it? It isn't obvious to me at all that throwing an exception in this case is the best behaviour. Throwing an exception when testing a value for 'truthiness' is extremely surprising.

On the other hand, I would strongly discourage 'if(x)' where x is a float that may be NaN purely because the 'correct' behaviour here isn't clear to me.




How about the case where x is (y > 0)? If y is NaN, shouldn't x be boolean-NaN? And shouldn't if(x) throw an exception? Or shouldn't (y > 0) throw an exception if you don't want boolean-NaNs?


That's easy: y > 0 is False, not NaN.

You may not think this is wise, but this is very much how comparisons with NaN are defined.

And I think this is better than exception raising. Again, I think it would be _really_ weird for simple value comparisons to throw.


> Again, I think it would be _really_ weird for simple value comparisons to throw.

But ... why?

You may say that NaN > 0 is defined as False, but we know that's not how programmers think, most of the time.

In code like if(y > 0) steer_car_to_left() I don't want the compiler or the IEEE standard to make any choices for me! Let it throw, so emergency systems can kick in.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: