дискуссии по теме

Поэтому его и не надо бросать - о чем я и говорю.



тогда в чем ее исключительность если я знаю что тут может произойти и могу написать обработчик на месте и продолжить выполнение программы а не игнорировать логику и последовательность выполнения программы перебрасывая выполнение программы куда то в конец.
Это типа goto против которого многие боряться только еще хуже -goto хоть в одном блоке кода а исключение может пролететь десяток исходников - и разбирайся что там случилось.
(Добавление)


никак
только если есть документация
иначе ковыряйтесь в коде. Еще один минус исключениям.
В яве хоть ситаксис обязвает указать какие исключения может выбрасывать функция.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Доказывать должна сторона, пытающаяся вести диалог конструктивно. Это к обоим сторонам относится.
Со стороны сторонников ексепшнов Stierus код привел. Я правда, не очень увидел в нем все преимущества)
Я свои основные мысли в предыдущих 2 постах описал.Если в стиле явадок описаны эти исключения, то при наведении мышкой будет выскакивать подсказка

вот мой код

Я вообще не увидел - то есть смысла в таком коде - ноль

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Каких ошибок?
Дико извиняюсь но когда ршибька в запросе то нужно исправлять код - не может быть никаких ощибок в запросе.
Емли юзер ввел неверныхх паротль - эо тоже не ощибка программы - это просто несоответствующие бизнес-данные - это предсказуемая ситуация которую нужно нормально обработать на месте и принять решение куда программа идет дальше.
Откуда вообще эта дикая идея что программа должны быть в одном месте а ошибки обрабатыватся в другом.

.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Я пока не увидел ни одного куска кода, работающего без исключений ... сплошное бла-бла-бла. Эксперты собрались и обсуждают абстрактных коней в вакууме

-А что означает API?
-Я даже не знаю, но что-то мне не нравится ... в слове всего 3 буквы, а ничего хорошего тремя буквами не назовут.
-Коллега, я думаю, вы не правы, не стоит так рано судить вещь лишь по названию
-нет-нет, я точно уверен, что ничего хорошего вещь с таким названием принести не может
-Хорошо, предлагаю обсудить полезность четкого соблюдения правил написания api на форуме php.su ...

Мне это будет удобным. Но не в такой степени чтоб на каждый if.

-----
Шта? Репозиторий?

скачай исходники например PHP или Mysql или Апач
(Добавление)


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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

В коде Stierus есть пример. Со словом @throws.Все же в пределах форума этого куска кода никто и не приведет. Кроме короткости написанного код ничего объективно не покажет. Удобно или не удобно это - можно будет все равно спорить до посинения. Чтобы реально продемонстрировать свою правоту, нужно сопровождать проект с ексепшнами и проект с ифами. И сравнивать простоту такого сопровождения, сравнивать наступленные грабли и пропущенные ошибки. А мини-куском кода на форуме никого не убедишь в субъективных вещах. Это все-таки субъективная вещь - мы ведь не можем цифрами измерить свою правоту. Так что здесь все-таки словесная перепалка более уместна.
Мы пишем более обоснованные вещи, чем это)

Да.
Это тоже да. Бросать исключения при неверном логине и пароле - такое бывает, но правильность этого сомнительная - я согласен. Но фатального в таком не увижу.
Я приводил пример с карандашами с Машей и Васей. Если мы смогли вычислить кол-во карандашей - хорошо. У нас в бизнес логике предусмотрено, что делать в этом случае. Еслине смогли - это исключительная ситуация.
Эта идея имеет много общего с отделением логики доступа к данным от бизнес-логики и отделения логики представления от них обоих.

Еще раз:


1. Противоречие. Мы пришли к тому, что есть такие ситауции, когда нужен ексепшн(которые нельзя предусмотреть), заметили, что мы не можем бросить ексепшн в тех случаях, когда не можем предусмотреть ситуацию, поэтому решили, что его вообще бросать не надо, но потом все-таки поняли, что есть ситуация, в которой надо. О чем это говорит? О том, что ты поплыл в дискуссии и твоя позиция не тверда.
2. Если в твоем коде есть то, что "нельзя предусмотреть" - это недостаток кода. Предусмотреть нужно всё (хотя, как правило, предусмотреть всё не возможно).
Данные, выходящие за предусмотренные рамки, отсутсвие доступа, разрыв коннекта, сигнал kill - всё это должно быть предусмотренно, и это не бизнес логика. Это логика исключительных ситауций.

Спор ни о чем. Я понимаю, что никто из нас не переубедит никого. Мы уже начинаем идти по кругу.в GOTO нет ничего плохого. Людям мало одного GOTO - придумали ексепшны.
Дело в том, что и тем, и другим надо грамотно пользоваться - и будет удобно, правильно и замечательно.
Можно и из ифов нагородить такое дерьмо, что в страшном сне не приснится.

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



Именно так - а не как вышеприведенном коде - использовать исключение вместо return.

(Отредактировано автором: 28 Октября, 2011 - 19:10:05)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

Почему? Я всё-таки напишу код.

да но в одном месте в коде класса работы с БД. Во втором варианте все верно если ограничится именно исключительной ситуацией "отвалились во время запроса"


"(или запрос неверный)" - а это косяк в коде который нужно выявить в результате тестирования и исправить.


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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

(речь о существующем логине)
Это ошибка. Я показываю пользователю сообщение об ошибке и прошу его что-нибудь сделать потому что сам не могу - не стану же я приписывать к его логину unqid() или еще что-то, делать его уникальным и успешно продолжать работу. Мы не можем знать, как тут поступить и что сделать с логином. Это самая настоящая исключительная ситуация на самом деле.

Вот именно что пользователь уже будет выполнять)

Ну он может произойти только в тех местах, где выполняется запрос к БД. Так что множество таких мест вполне определено и конечно.
Но тут, как ни странно, мы можем попробовать что-то сделать (в отличие от повторяющегося логина). Мы можем предпринять N повторных попыток выполнить запрос. Можем инициировать переключение на работу с зеркалом источника данных и продолжить работу. Можем пнуть скрипт, который поднимет упавший сервер БД и повторить попутку запроса.
Есть варианты. Несколько экзотические, но есть. А в случае с логином нет никаких вариантов кроме как прекратить работу и попросить пользователя ввести логин.

Так что по твоей логике стоило бы бросить ексепшн при неверном логине, но не стоит бросать его фейле с коннектом
(Добавление)
Да, надо. Но вероятность пропустить неверный запрос есть, так что можно завернуть этот код в исключения. Если это исключение никогда в жизни не бросится - мы ничего не проиграем. Если бросится - увидим и исправим.
"Неверный запрос - это косяк в коде" - с этим утверждением никто не спорит.

Ошибка пользхователя а не программы.



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



то есть в стопицот местах особенно если это большая и сложная ЦМС или портал.


Да. Но неопределено в каком коонкретно месте и в какое время.




Тогда исключения не будет. И вообще ошибки не будет - функция отработает штатно.

Это не по моей логике.




Да, есть вероятность что не все баги будут выловлены сразу. Но как только вылезет следует исправить и ситуация исчезнет. Но вы не можете предусмотреть все баги и завернутиь их в исключение. Например деление на ноль - не уверен что будет выброшено исключение как в случае с БД где библиотека работы с БД его выьбросит.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore