А почему в java нету готовых методов, которые бы позволяли парсить числа, не кидая исключений? Т.е. возвращали бы true+число, либо false, типа как int.TryParse в дотнете.
Ситуация, когда нормальная работа приложения либо модуля не может быть продолжена обычным образом, и вам необходимо вернуться, возможно, на несколько уровней вложенности в первоначальное состояние, передав наверх информацию о ситуации.
А не факт, что IOException - это правильное архитектурное решение. У нормальных людей эти операции возвращают результат операции, число там записанных байт и т.п. Там исключение - как корове седло.
Тру исключение то, которое спроектировано для выхода на определенный уровень обработки наверх. То есть правильно было бы иметь по 2 версии функций, с исключениями и без них. Просто использование исключений вместо кодов возврата приводит к тому, что 50 строчек линейного рабочего кода, например, для работы с файлом, превращаются в гору try блоков, которые могут быть не нужны.
правильнее, мне кажется, было бы все-таки поиметь на месте код возврата и если нужно - бросить исключение. Потому что чаще это при таких операциях не сильно нужно. Сделать из кода возврата исключение пишется лаконичнее, чем сделать код возврата из исключения :)
Ребе. Вот смотрите, решила индустрия вас послушать и наклепала дублирующих функций с кодами возврата. Хомячки обрадовались (это ж не надо теперь эти долбаные исключения обрабатывать) и начали их использовать. А принуждения к верификации кода возврата -- нету! Нету, блять, ващще! Кроме вменяемого тимлида, который будет каждый день проверять выхлоп и все фиксы и тэпэ и тэдэ.
А теперь представьте во что превратятся либы через пару лет. Как вы будете материться на то, что "какого хера оно продолжает\дохнет\подставьте сами без какой либо инфы?".
Очень простой. Если работу можно продолжать - исключение кидать не принято. Исключения - для случаев, когда надо свалится в корень исполняемого потока (main loop или там обработчик выдающий 500 в веб-сервисе). Делать логику на исключениях - очень нехорошо, но конкретно в данном случае жаба вынуждает это делать.
Потом этот налл удетит по веб-сервису на N удаленных систем. Там сохранится в базах, потечет по бизнес-процессам и через пол года на другом континенте начнет вываливаться NPE. Нал он такой, да. Как и любители нала.
Про острое желание я ничего не говорил. А про случайные ситуации - говорил. И от таких ситуаций взрослые люди стараются себя страховать. Предохранители делают на приборах или эксепшны в коде. От всех несчастных случаев это не застрахует, но это не повод расслабляться и рассказывать про отстреленную ногу, случайность, карму, фазы луны и прочую ересь.
no subject
no subject
Опять же, что плохого в исключениях?
no subject
no subject
no subject
no subject
Чем принципиально это отличается от IOException?
no subject
no subject
no subject
То есть правильно было бы иметь по 2 версии функций, с исключениями и без них.
Просто использование исключений вместо кодов возврата приводит к тому, что 50 строчек линейного рабочего кода, например, для работы с файлом, превращаются в гору try блоков, которые могут быть не нужны.
no subject
В жабе конечно есть Checked Exceptions, но при правильном использовании вполне полезны.
no subject
Сделать из кода возврата исключение пишется лаконичнее, чем сделать код возврата из исключения :)
no subject
А теперь представьте во что превратятся либы через пару лет. Как вы будете материться на то, что "какого хера оно продолжает\дохнет\подставьте сами без какой либо инфы?".
no subject
Если работу можно продолжать - исключение кидать не принято.
Исключения - для случаев, когда надо свалится в корень исполняемого потока (main loop или там обработчик выдающий 500 в веб-сервисе).
Делать логику на исключениях - очень нехорошо, но конкретно в данном случае жаба вынуждает это делать.
no subject
Исключение кидаются когда произошло нечто неожиданное с точки зрения разработчика.
parseInt() ожидает увидеть число. А получило. - вполне неожиданное событие.
Ожидали прочитать из файла, а он закончился - тоже.
Но и то, и другое можно сделать на статусах, как C.
no subject
no subject
Но вот с числами.. можно конечно сделать Integer Integer.parseInt() и возвращать null если не удалось распарсить.
no subject
no subject
no subject
no subject
На грабли всегда наступить можно.