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?

6
  • Because ABC is not a valid format of number and it matches the behavior of the other boxed classes' parse* methods Commented Jan 27, 2015 at 17:02
  • @ratchetfreak Hm, all the other boxed classes'parse* methods have no valid NaN-value. Integer have no NaN, Float has!
    – Grim
    Commented Jan 27, 2015 at 17:06
  • 1
    add long, char, short, byte and boolean then it's 6v2 Commented Jan 27, 2015 at 17:07
  • @ratchetfreak ah ok
    – Grim
    Commented Jan 27, 2015 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
    Commented Jan 27, 2015 at 17:14

3 Answers 3

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.

4
  • So NaN means they realy try to enter a double?
    – Grim
    Commented Jan 27, 2015 at 17:09
  • @PeterRader I don't think people type NaN by accident very often.
    – Doval
    Commented Jan 27, 2015 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
    Commented Jan 27, 2015 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
    Commented Jan 27, 2015 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!

1
  • How can this answer be worth a downvote?
    – user949300
    Commented Jan 28, 2015 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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