1

This code:

Double.parseDouble("ABC")

throws a NumberFormatException.

Why is it wrong to expect a Double.NaN (NaN is literally Not-A-Number).

A working example is this:

public static void main(String[] args) {
    System.out.println("Is ABC a number? " + Double.isNaN(Double.parseDouble("ABC"));
}

I expect Is ABC not a number? true as output.

Why must this be an Exception?

  • Because ABC is not a valid format of number and it matches the behavior of the other boxed classes' parse* methods – ratchet freak Jan 27 '15 at 17:02
  • @ratchetfreak Hm, all the other boxed classes'parse* methods have no valid NaN-value. Integer have no NaN, Float has! – Peter Rader Jan 27 '15 at 17:06
  • 1
    add long, char, short, byte and boolean then it's 6v2 – ratchet freak Jan 27 '15 at 17:07
  • @ratchetfreak ah ok – Peter Rader Jan 27 '15 at 17:07
  • 5
    True, 'NaN' is literally deciphered as 'Not-A-Number', but id does not denote arbitrary entity other than number. What it denotes is sort of placeholder of a numeric value, a representation which may arise during floating-point calculations (such as (+INF) + (-INF) or 0 / 0). – ach Jan 27 '15 at 17:14
5

NaN has a very specific meaning as the result of an undefined numerical operation such as division by zero or taking the square root of a negative number (within the realm of real numbers). It's not an appropriate return value from code that parses a floating point number.

Code like that should signal an error when it comes across text that can't be parsed as a number.

Also, as others have mentioned, it's a consistency issue. Only floating point values even have a NaN. Integer and boolean types don't. parseX() should behave the same way in all cases where possible.

This is called the principle of least surprise. That is, design things in the most consistent way possible to avoid surprising others using your APIs.

1

This lets you easily detect the cases where the input is completely nonsensical. You can parse the string "NaN" and get NaN, so if the user wanted to give you NaN, he could type that. The fact that you received "ABC" means they weren't even trying to enter a double at all.

  • So NaN means they realy try to enter a double? – Peter Rader Jan 27 '15 at 17:09
  • @PeterRader I don't think people type NaN by accident very often. – Doval Jan 27 '15 at 17:11
  • "NaN" might be in a text file. So when reading a text file you can differentiate a NaN from garbled gibberish. – user949300 Jan 27 '15 at 17:43
  • @user949300 I'm not sure what's your point. If a text file appears to contain "garbled gibberish" and you don't know where it came from or what it's supposed to mean, I wouldn't assume that the string "NaN" has any significance. – Doval Jan 27 '15 at 17:48
1

In addition to the good answer by @Doval, throwing a NumberFormatException is more general: it works for similar methods like Integer.parseInt(). There is no NaN equivalent for ints, shorts, etc.

So, throwing a NumberFormatException is both more specific/informative than returning NaN, it is also more generalizable.

That's truly a win-win!

  • How can this answer be worth a downvote? – user949300 Jan 28 '15 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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