А почему в java нету готовых методов, которые бы позволяли парсить числа, не кидая исключений? Т.е. возвращали бы true+число, либо false, типа как int.TryParse в дотнете.
Выше уже писали - не смотря на то, что эксепшены для исключительный ситуаций, в данном случае подобное их использование в виде управляющих конструкций навязано отсутствием других вменяемых вариантов.
Никак не оправдано. В данном случае надо проверить, правильный ли номер, а не парсить, поэтому надо использовать NumberFormat в месте возникновения сомнительного стринга-интежера. Про сами эксепшны вопрос, скорее, академический. Вот пример, у вас пользователь вводит логин и пароль. Факт ввода неправильного пароля это эксепшн? К вашему коду претензия другого плана. Что толку от вашего возвращения некого дефолта? Вам в месте вызова этой функции надо проставлять этот дефолт, обрабатывать потом результат, не пришёл ли дефолт. Не говоря о том, что в таком случае парсинг самого дефолта невозможен. Всё это в совокупности - индусятина. Лучше уж сразу в месте вызова ловить эксепшн и обрабатывать.
no subject
за ловлю голого Exception нужно пальцы дверью зажимать. сначала на ногах, при рецидиве - на руках и вон из профессии :)
no subject
no subject
Эксепшн это дорогая штука для жаба машины. То что вы написали это, несмотря на корректную работу, обычная индусятина.
no subject
no subject
Про сами эксепшны вопрос, скорее, академический. Вот пример, у вас пользователь вводит логин и пароль. Факт ввода неправильного пароля это эксепшн?
К вашему коду претензия другого плана. Что толку от вашего возвращения некого дефолта? Вам в месте вызова этой функции надо проставлять этот дефолт, обрабатывать потом результат, не пришёл ли дефолт. Не говоря о том, что в таком случае парсинг самого дефолта невозможен. Всё это в совокупности - индусятина. Лучше уж сразу в месте вызова ловить эксепшн и обрабатывать.