LongValue does not catch NumberFormatException

[emopers]

LongValue.java calls java.lang.long.parseLong without first checking whether the argument parses. This lead to an uncaught NumberFormatException: Oracle Java 7 API specification.

This pull request adds a check with a more helpful exception message and also fix an indentation issue at line no. 38.

[wumpz]

But were is the problem. The parser itself ensures that only long values are passed to LongValue. So do you have a problematic SQL, that produces a NumberFormatException?

[emopers]

Re-opening this pull request because, while JSQLParser may indeed ensure that only valid values are passed to the LongValue constructor, LongValue is a public class and its constructor is public. Thus, code that depends on JSQLParser without properly sanitizing their input could run into this problem.

For example, when the snippet below is run:

import net.sf.jsqlparser.expression.LongValue;

public class Test {
    public static void main(String[] args) {
        new LongValue("random");
    }
}

The exception would be thrown without any useful debugging information:

/tmp$ java -cp .:JSqlParser/target/jsqlparser-0.9.6-SNAPSHOT.jar Test
Exception in thread "main" java.lang.NumberFormatException: For input string: "random"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Long.parseLong(Long.java:441)
    at java.lang.Long.parseLong(Long.java:483)
    at net.sf.jsqlparser.expression.LongValue.<init>(LongValue.java:37)
    at Test.main(Test.java:5)

[coveralls]

Coverage increased (+0.3%) to 83.771% when pulling 4fad4af on emopers:long_bad_76 into f5b515b on JSQLParser:master.

[wumpz]

Agreed after JSqlParser is more and more used for SQL building purposes.