Почему это NumberFormatException? - PullRequest
11 голосов
/ 03 февраля 2010

У меня есть эта трассировка стека (часть)

Servlet.service() for servlet action threw exception
java.lang.NumberFormatException: For input string: "37648"
 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Long.parseLong(Long.java:403)
 at java.lang.Long.valueOf(Long.java:482)
 at java.lang.Long.decode(Long.java:593)

в одном из моих лог-файлов Я не знаю, что было настоящей строкой ввода. Но пользователь сделал так же, как в стеке.

Как может происходить такая трассировка стека?

1 Ответ

30 голосов
/ 03 февраля 2010

Возможно, потому что они имеют ведущий ноль на входе.

Это отлично работает:

public class DecodeLong
{
    public static final void main(String[] params)
    {
        long    l;

        l = Long.decode("37648");
        System.out.println("l = " + l);
    }
}

Но если вы измените это:

l = Long.decode("37648");

к этому:

l = Long.decode("037648");

... восьмеричное значение становится недействительным, и исключение из Long.parseLong не включает ведущий ноль :

Exception in thread "main" java.lang.NumberFormatException: For input string: "37648"
        at java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.lang.Long.parseLong(Unknown Source)
        at java.lang.Long.valueOf(Unknown Source)
        at java.lang.Long.decode(Unknown Source)
        at DecodeLong.main(DecodeLong.java:24)

Это не включает его, потому что decode вызывает parseLong без нуля, но с базой, установленной на 8.

Поговорим о неизвестности. :-) Так что, если вы обновите свою программу для обработки исключения, показав фактический ввод, вы, вероятно, найдете что-то в этом роде.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...