![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Ну а чем это не подходит к ситуации, когда мы ожидаем распарсит число, а не получается? Тут тоже возможно нужно передать информацию на уровень выше?
Чем принципиально это отличается от IOException?
Чем принципиально это отличается от IOException?
А не факт, что IOException - это правильное архитектурное решение. У нормальных людей эти операции возвращают результат операции, число там записанных байт и т.п. Там исключение - как корове седло.
Да. С этим согласен. Сам переписывал парсера, который не проверял границы, а кидал Out Of Bounds. Стало короче и даже быстрее.
Но вот с числами.. можно конечно сделать Integer Integer.parseInt() и возвращать null если не удалось распарсить.
Но вот с числами.. можно конечно сделать Integer Integer.parseInt() и возвращать null если не удалось распарсить.
Тру исключение то, которое спроектировано для выхода на определенный уровень обработки наверх.
То есть правильно было бы иметь по 2 версии функций, с исключениями и без них.
Просто использование исключений вместо кодов возврата приводит к тому, что 50 строчек линейного рабочего кода, например, для работы с файлом, превращаются в гору try блоков, которые могут быть не нужны.
То есть правильно было бы иметь по 2 версии функций, с исключениями и без них.
Просто использование исключений вместо кодов возврата приводит к тому, что 50 строчек линейного рабочего кода, например, для работы с файлом, превращаются в гору try блоков, которые могут быть не нужны.
можификация переменных зло
Неумение языка возвращать tuple тоже зло.
Неумение языка возвращать tuple тоже зло.
совершенно согласен. Тут tuple при возврате было бы самое то, что нужно.
Это крайность имхо.
Исключение кидаются когда произошло нечто неожиданное с точки зрения разработчика.
parseInt() ожидает увидеть число. А получило. - вполне неожиданное событие.
Ожидали прочитать из файла, а он закончился - тоже.
Но и то, и другое можно сделать на статусах, как C.
Исключение кидаются когда произошло нечто неожиданное с точки зрения разработчика.
parseInt() ожидает увидеть число. А получило. - вполне неожиданное событие.
Ожидали прочитать из файла, а он закончился - тоже.
Но и то, и другое можно сделать на статусах, как C.
Ну почему же? Что-то пошло не так при обработке файла? IOException и обрабатывать его на нужном уровне. Код вполне линейным получается.
В жабе конечно есть Checked Exceptions, но при правильном использовании вполне полезны.
В жабе конечно есть Checked Exceptions, но при правильном использовании вполне полезны.
правильнее, мне кажется, было бы все-таки поиметь на месте код возврата и если нужно - бросить исключение. Потому что чаще это при таких операциях не сильно нужно.
Сделать из кода возврата исключение пишется лаконичнее, чем сделать код возврата из исключения :)
Сделать из кода возврата исключение пишется лаконичнее, чем сделать код возврата из исключения :)
Ну а как иначе жить
Потом этот налл удетит по веб-сервису на N удаленных систем. Там сохранится в базах, потечет по бизнес-процессам и через пол года на другом континенте начнет вываливаться NPE. Нал он такой, да. Как и любители нала.
Ну ногу-то практически всегда отстрелить можно. Особенно при остром желании.
При этом комментатор выше (которому посмел ответить volodimir_k) конечно же привнес много полезной и нужной информации в дискуссию.
а что, об этом нельзя говорить вслух?
Про острое желание я ничего не говорил. А про случайные ситуации - говорил. И от таких ситуаций взрослые люди стараются себя страховать. Предохранители делают на приборах или эксепшны в коде. От всех несчастных случаев это не застрахует, но это не повод расслабляться и рассказывать про отстреленную ногу, случайность, карму, фазы луны и прочую ересь.
и еще сервер в инете поднять. и чтобы по restу запрос слался. с ssl, sso, понятное дело, и лоад балансом с отказоустойчивостью.
И кешировать обязательно. Зачем каждый раз вычислять?
Да ладно, две строки кода вас не должны вгонять в депрессию. Можете как какой-нибудь программист из коворкинга сделать свой проект на гитхабе с оберткой над Integer.parseInt из двух строк. Это сейчас в тренде.
Ну так и говорю, что то, что parseInt() кидает исключение - вполне нормально.
На грабли всегда наступить можно.
На грабли всегда наступить можно.
C т.з. требований на вашем уровне- вполне возможно. С т.з. метода парсинга строки в инт неподходящая строка- это ошибка. В жаве принято обрабатывать ошибки консистентно- исключениями.
Ну мы тут обсуждаем "как было бы лучше" :)
Сферически - идеальные языки, с кортежами на выходе и т.п. Ням-ням.
Сферически - идеальные языки, с кортежами на выходе и т.п. Ням-ням.
с коттеджами в ратомке на испанском побережье- это мысль.
У нас в оперденях есть такой возвращаемый тип. Крайне полезен.
Page 3 of 5