metaclass | java try parse integer

А в чем их возвращать? Можно сделать class что-то вроде MutableInteger, но как-то не очень красиво.
Можно возвращать Object[] - но это совсем уж извращение.

Чем так сильно отличает возвращение статуса от кидания исключения?

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

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

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

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

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

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

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

Edited 2013-03-21 10:27 (UTC)

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

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

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

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

(no subject)

kzn.livejournal.com - 2013-03-21 10:39 (UTC) - Expand

(no subject)

vp.livejournal.com - 2013-03-21 10:42 (UTC) - Expand

(no subject)

kzn.livejournal.com - 2013-03-21 10:56 (UTC) - Expand

(no subject)

vp.livejournal.com - 2013-03-21 10:58 (UTC) - Expand

(no subject)

sil-e-nt.livejournal.com - 2013-03-22 07:50 (UTC) - Expand

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

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

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

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

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

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

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

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

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

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

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

(no subject)

henu3detb.livejournal.com - 2013-03-21 11:49 (UTC) - Expand

(no subject)

kzn.livejournal.com - 2013-03-21 11:59 (UTC) - Expand

можификация переменных зло
Неумение языка возвращать tuple тоже зло.

совершенно согласен. Тут tuple при возврате было бы самое то, что нужно.

C т.з. требований на вашем уровне- вполне возможно. С т.з. метода парсинга строки в инт неподходящая строка- это ошибка. В жаве принято обрабатывать ошибки консистентно- исключениями.

Ну мы тут обсуждаем "как было бы лучше" :)
Сферически - идеальные языки, с кортежами на выходе и т.п. Ням-ням.

с коттеджами ~~в ратомке~~ на испанском побережье- это мысль.

У нас в оперденях есть такой возвращаемый тип. Крайне полезен.

Еще вот тут отмечусь. Вот сделали туплом аутпут, ок, облегчили себе жизнь и вместо исключения пользуем дефолтное значение.
Берет юзверь вашу прогу, вводит какую-нибудь шнягу, верную с его точки зрения (можно я не буду придумывать варианты?) А потом несколько дней ебется в поисках решения, хули получается совершенно другое значение на выходе?

А кто говорил о каких-то дефолтных значениях?
Если все не ок, то возвращается кортеж из булена об ошибке и кода ошибки. Если все ок, то возвращается тупл с буленом и с полученным значением.

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