java try parse integer

[metaclass]

А почему в java нету готовых методов, которые бы позволяли парсить числа, не кидая исключений?
Т.е. возвращали бы true+число, либо false, типа как int.TryParse в дотнете.

Comments

[kzn.livejournal.com]

Хмм. откуда такой постулат?
В исходном посте в C# - tryParse - попробовать распарсить. в Java - parseInt() - требует распарсить. Вполне логично по-моему.

[vp.livejournal.com]

Так мы дойдем, что проверка if() при не выполнении условия тоже будет бросать исключения вместо того, чтобы ветвиться.

[kzn.livejournal.com]

Не надо преувеличивать :) Скажем isInteger() исключений бросать не должна.

Опять же, что плохого в исключениях?

[vp.livejournal.com]

Есть мнение, что исключение - это исключительная ситуация. По определению здесь нет факта исключительной ситуации.

[kzn.livejournal.com]

Каков критерий исключительной ситуации?

[vp.livejournal.com]

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

[kzn.livejournal.com]

Ну а чем это не подходит к ситуации, когда мы ожидаем распарсит число, а не получается? Тут тоже возможно нужно передать информацию на уровень выше?

Чем принципиально это отличается от IOException?

[vp.livejournal.com]

А не факт, что IOException - это правильное архитектурное решение. У нормальных людей эти операции возвращают результат операции, число там записанных байт и т.п. Там исключение - как корове седло.

[kzn.livejournal.com]

Ну ок. А какое труъ исключение?

[vp.livejournal.com]

Тру исключение то, которое спроектировано для выхода на определенный уровень обработки наверх.
То есть правильно было бы иметь по 2 версии функций, с исключениями и без них.
Просто использование исключений вместо кодов возврата приводит к тому, что 50 строчек линейного рабочего кода, например, для работы с файлом, превращаются в гору try блоков, которые могут быть не нужны.

[kzn.livejournal.com]

Ну почему же? Что-то пошло не так при обработке файла? IOException и обрабатывать его на нужном уровне. Код вполне линейным получается.

В жабе конечно есть Checked Exceptions, но при правильном использовании вполне полезны.

[vp.livejournal.com]

правильнее, мне кажется, было бы все-таки поиметь на месте код возврата и если нужно - бросить исключение. Потому что чаще это при таких операциях не сильно нужно.
Сделать из кода возврата исключение пишется лаконичнее, чем сделать код возврата из исключения :)

[sil-e-nt.livejournal.com]

Ребе. Вот смотрите, решила индустрия вас послушать и наклепала дублирующих функций с кодами возврата. Хомячки обрадовались (это ж не надо теперь эти долбаные исключения обрабатывать) и начали их использовать. А принуждения к верификации кода возврата -- нету! Нету, блять, ващще! Кроме вменяемого тимлида, который будет каждый день проверять выхлоп и все фиксы и тэпэ и тэдэ.

А теперь представьте во что превратятся либы через пару лет. Как вы будете материться на то, что "какого хера оно продолжает\дохнет\подставьте сами без какой либо инфы?".

[metaclass.livejournal.com]

Очень простой.
Если работу можно продолжать - исключение кидать не принято.
Исключения - для случаев, когда надо свалится в корень исполняемого потока (main loop или там обработчик выдающий 500 в веб-сервисе).
Делать логику на исключениях - очень нехорошо, но конкретно в данном случае жаба вынуждает это делать.

[kzn.livejournal.com]

Это крайность имхо.

Исключение кидаются когда произошло нечто неожиданное с точки зрения разработчика.

parseInt() ожидает увидеть число. А получило. - вполне неожиданное событие.

Ожидали прочитать из файла, а он закончился - тоже.

Но и то, и другое можно сделать на статусах, как C.

[metaclass.livejournal.com]

с if часть алгоритмов сильно короче и нагляднее. Ну, еще насчет производительности вопрос сложный.

[kzn.livejournal.com]

Да. С этим согласен. Сам переписывал парсера, который не проверял границы, а кидал Out Of Bounds. Стало короче и даже быстрее.

Но вот с числами.. можно конечно сделать Integer Integer.parseInt() и возвращать null если не удалось распарсить.

[henu3detb.livejournal.com]

Потом этот налл удетит по веб-сервису на N удаленных систем. Там сохранится в базах, потечет по бизнес-процессам и через пол года на другом континенте начнет вываливаться NPE. Нал он такой, да. Как и любители нала.

[kzn.livejournal.com]

Ну ногу-то практически всегда отстрелить можно. Особенно при остром желании.

[henu3detb.livejournal.com]

Про острое желание я ничего не говорил. А про случайные ситуации - говорил. И от таких ситуаций взрослые люди стараются себя страховать. Предохранители делают на приборах или эксепшны в коде. От всех несчастных случаев это не застрахует, но это не повод расслабляться и рассказывать про отстреленную ногу, случайность, карму, фазы луны и прочую ересь.

[kzn.livejournal.com]

Ну так и говорю, что то, что parseInt() кидает исключение - вполне нормально.

На грабли всегда наступить можно.