3 ms·
I'd definitely go with throw - it's indicative of a logic bug, and I'd rather notice it during dev (or if not, catch in prod, complete with stack trace and what
by pocketarc 3y ago
I'd definitely go with throw - it's indicative of a logic bug, and I'd rather notice it during dev (or if not, catch in prod, complete with stack trace and whatnot), than to have it silently corrupting anything that relies on that calculation happening correctly, without me even being aware of it.
Like, if I'm doing x + y, and y just accidentally happens to contain the wrong data because of a mistake in the code, a NaN means the code will proceed as normal, and nobody will notice anything is wrong. If it's not a noticeable bug, it might be a long time until it's spotted by someone. And when they do, who knows how much damage it will have caused.
- lumost 3y agoI'd always go with NaN. In dataprocessing, it's common to encounter NaNs due to bad data - these records can be filtered out to allow the process to continue. The records which resulted in NaN can be flagged for follow-up. As a program author, I'd expect that it's my choice how to handle this situation. I don't want libraries making arbitrary decisions about how my code should work.