Подтвердить что ты не робот

Почему это NumberFormatException?

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

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)

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

Как может возникнуть такая stacktrace?

4b9b3361

ОТВЕТЫ

Ответ 1

Вероятно, потому что они имеют начальный ноль в своем входе.

Это нормально:

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.

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