Вот пытаюсь осознать необходимость вставлять Исключения в свой проект. И чем больше разбираюсь, тем больше задаю себе вопрос: "А зачем оно надо?"

Моё размышление примерно такое..

- Почему я перед использованием чего-либо не могу сначала проверить на существование этого чего-либо?

- Если нужно чтобы "сломанный" код продолжил работать, то зачем? Ведь я понимаю что что-то не заработало, но работа продолжилась, а это может привести к плохим последствиям

- Если мне нужна отладка кода и получение что и где работает, то почему бы мне просто не включить вывод ошибок и (или) просматривать логи сервера?

- Зачем мне вообще ловить ошибку, а не пытаться её избежать?

Вообще, использование исключений или статусных сообщений об ошибках - это как бы условно - холивар. 
По идее есть 2 стиля разработки приложений.
1. Использование статусных сообщений об ошибках в качестве возвратов из функций.
2. Использование исключений. 
Вкратце, идеология работы с исключениями следующая:
Вы пишете приложение так, будто бы оно работает в номинальном режиме. В случае возникновения "нештатных" ситуаций - бросаете исключение.
Плюсы от работы с исключениями: все их можно ловить и обрабатывать в одном месте, и свои, и системные.
Минусы - после работы с использованием статусных сообщений об ошибках в возвратах функций - это ой как непривычно.

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

Добавлено через 14 минут и 58 секунд
Вообще, перечитал ваши вопросы отвечу об исключениях более глобально:
Исключения - это способ работы программы в нештатном состоянии.


1. Проверку на существование чего-либо можно возложить на исключение. т.е. система считает, что что-либо, существует. А если нет, то меры принимаются в блоке отлова исключений (в идеальном случае - он один на всю систему).
2. Необходимость в работоспособности сломанного кода - диктуется требованиями к надежности и работоспособности системы.
3. Логирование системы можно осуществить и с исключениями и без них.
4. Некоторых ошибок избежать, теоретически, невозможно, так как вы можете и не знать о том, что они могут возникнуть. Как вы будете избегать ошибку, если не знаете - где она?

Принцип работы исключений я понимаю. Я не понимаю их такую великую значимость.. Разве при написании кода я не должен избавляться от "нештатных" ситуаций?

Допустим есть некая функция деления которая может получить ноль и при делении конечно же будет ошибка. Так вот, зачем мне отлавливать это если я сразу могу предусмотреть "правильную" реакцию.


Например? И почему же я не буду знать где она произошла?

Gold Dragon, я еще раз повторюсь - использование исключений - это стиль написания программы, не более. Выбор стиля определяется стандартом языка, решаемыми задачами, требованиями к проекту. Если проект вы разрабатываете самостоятельно и в одиночку - вопрос использования исключений - исключительно ваше личное дело. 


1. Если вы используете чужую библиотеку.
2. Банально при работе с СУБД.
Использование исключений - избавляет от необходимости постоянно проверять по ходу выполнения программы возвращаемые статусы выполнения функций.

Я так понял, свой проект вы разрабатываете на PHP.  Используете ли вы ООП в своём проекте?

Конечно.. Модернизирую CMS, т.е. избавляюсь от пережитков PHP < 5 и прибавляю хорошести PHP > 5.3

Вот и я про это... Если потому что "так принято" или "так правильнее", то просто не осознаю нужности 

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

PSS
Мне кажется что исключения тоже из этой области и нужны в большей части на стадии проектирования и осознания идеи

Gold Dragon, про ООП я спросил по причине того, что идея использования исключений хорошо сочетается с идеями Объектно-Ориентированного Программирования. Но единственно верной и обязательной, естественно, не является. Исключения - полезный инструмент в ООП. Главное - что бы исключения хорошо сочетались с общей концепцией проекта и их использование должно быть заложено на стадии проектирования. Исходя из этого, могу лишь дать совет.
Если вы занимаетесь рефакторингом проекта и ранее в нем исключения не использовались, лучше оставить всё как есть т.е. исключения в проект не вводить, есть риск сильно всё попортить.
Если собираетесь спроектировать проект заново и с использованием ООП. Продумайте концепцию использования исключений на  этапе проектирования (не конструирования!) классов.

переход на PHP 5.3+ приводит к замене не только функций, но и к изменению логики. По моим подсчётам будет переписано практически 50%. По этому  решил осознать необходимость включение в проект исключений. особого труда это конечно не составит. А вот стоит ли овчинка выделки, узнать хочется 

 "Человеку свойственно ошибаться", -- говорили ещё в Древнем Риме. 
"Errare humanum est."

Даже опытные люди, набирая код, могут забыть что-то элементарное. Потому в некоторых языках программирования, например в Java, во всех случаях, когда ошибка может "подвесить" всю систему, принудительно заставляют программиста использовать исключения. И это не из занудства, а наоборот, -- выигрывают от этого все. Надёжность программного обеспечения, называется. 

Программист, потратив лишнюю минутку, потом может выиграть время, в течение которого он бы долго искал по своему коду исходника, что же не так.

Gold Dragon, если вы проект перепроектируете с использованием ООП, то думаю, что заюзать исключения - стоит. Если производите рефакторинг (качественное улучшение кода без изменения функциональности и потери работоспособности) - лучше оставить все по старому. Слишком уж сильно должна будет поменяться логика. Не стоит насильно внедрять подобные вещи, лучше их заложить в новом проекте, иначе просто - опасно.
Просто, вам нужно просечь фишку от использования исключений, вопросов бы и не возникло вовсе.

Добавлено через 13 минут и 10 секунд
  кто заставляет?

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


Произошёл сбой при работе с запросом на удалённый сервер (сервис), не важно по какой причине (неправильный указан хост или сам сервис не ответил вовремя). В методе запроса есть путь алгоритма прямолинейный, что означает высокую читаемость кода и более правильное построение функции (это кстати к Zerstroer, про возращение статусов из функций/методов: обратите внимание на строго типизированные языки они задают один тип возврата, что само по себе правильно), но при этой ситуации мы как бы говорим что не знаем что делать и отдаём на откуп тем кто может сделать и присваиваем тип исключения например NotShowException (к таким же исключениям относятся и DBException и др. системные, которые не стоит показывать пользователю). При перехвате такого исключения, "клиент", на основании типа, может реализовать алгоритм например логирования или вывода пользователю ошибки и обращения к администрации, или приостановить и попытаться заново подключиться к сервису. 
То есть логику исключительных ситуаций клиент может определять по своему, при чём клиенты могут быть разными и реализовывать по разному. Предугадываю вопрос, какая разница , если возвращать статус.
Возвращать статус можно, и встречный вопрос а если сбоев в одном методе более напримр 3, как начинает код захламляться и это с учётом того что эти статусы нужно где то определить и научить клиента их понимать и различать, это первое.
Второе, сообщение об ошибке, номер строки, файл вызвавший ошибку и трассировка к этой ошибке - только этот набор уже должен перетянуть весы , так как всё это целыми массивами отдавать из метода это безумие.
Третье, при генерации исключения можно в объект заносить так же свои данные, например отладочные сообщения или объекты формы с ошибками, чего не сделаешь с помощью возвращения статусов ошибок (ну или можно но это будет куча хлама и костылей)
Вчетвёртых, чисто концептуально исключения это поток ошибок, что отделяет концепцию управлением ошибками (безопасное программирование) и основные потоки алгоритмов.
В пятых, улучшается проектирование методов и классов за счёт отделения нормальной логики от логики ошибок, то есть программист сосредотачивается на нормальном ходе алгоритма и его оптимизации, а исключения просто отмечает псевдокодом. 

Это сообщение отредактировал(а) Sentox - 3.7.2012, 00:02

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

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

В том и смыл, что происходит остановка и ничего не происходит. Но есть ошибки которые PHP просто не считает таковыми. Например тот же сценарий удалённой работы или ошибки БД (не синтаксических запросов!, а допустим не существующих записей) при этом требуется выводить страницу с извинениями пользователю. Для этого в поток типа исключения например NotFoundException  пускаем сообщения, при чём записываем в лог полностью сообщение, файл строку и трассировку, и здесь же выводим страницу с извинениями или с обращением в службу поддержки. То есть ошибки чисто сценарные а не критические или предупреждения.

Тогда совсем не понятно.. Зачем мне этот обработчик исключений, когда я могу в скрипте сделать эту проверку и красиво преподнести это пользователю, а не выдавать ошибки..

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

Добавлено через 1 минуту и 17 секунд

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

Zerstroer, так я не спорю  Я просто жду чтобы кто-то пришёл и показал что это "ОФИГЕННАЯ ВЕСТЧ"...

Но на сегодня это систематизированная обработка ошибок, которая в PHP 5 должна заменить все пользовательские разработки  Т.е. если проект когда-то работал на PHP 4 или работает на ней, то скорее всего механизм обработки ошибок уже есть. а значить ничего нового использовать не нужно... А вот для новых может быть лучше использовать "красивую" обработку ошибок

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

1. этап инициализация приложения. 
- подгрузка требуемых dll
- создание формы 
- загрузка данных реестра
- оторажение загруженных данных

так вот внутри этого логического блока у нас может произойти миллион и одна ошибка. (нет dll, нет прав на доступ к реестру, нет нужной ветки, нехватка памяти и т.п.)


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

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


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

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

согласен полностью, по крайней мере на сегодняшнем этапе. И согласен что в PHP это немного другое нежели в других языках 

да ладно   это очень не удачное сравнение...

по больному задел?! )))



тут все зависит от его использования.
как я вижу PHP на 90% испольузется как полу-программирование, но никто ведь не запрещает тебе на нем написать свой сервис который будет работать так-же как я описывал (ну за исключением того, что вместо формы будет скажем - удаленный терминал) 

Исключения - это "ОФИГЕННАЯ ВЕСТЧ"... только, применять их нужно только по мере необходимости. Во всей ветке нет ни единого ложного утверждения. Рассматривайте исключения как удобный и эффективный инструмент. Целесообразность их использования - зависит от многих причин. Не нужно насиловать систему и себя, если вы не до конца осознаете весь профит от их использования - пользуйтесь возвратами статусов из функций, в вашем случае на данном этапе профессионального развития этот способ будет работать эффективнее.
Вкуснее будет осознать цимес от исключений - если перепроектируете систему заново. Пишу основываясь на собственном опыте, сам сравнительно недавно "просёк фишку" исключений.

PS
Zerstroer, ты абсолютный позитив  Главное береги это качество.. а то не бывает так чтобы добрым для всех...
+1

Это сообщение отредактировал(а) Gold Dragon - 3.7.2012, 21:14

  это я то добрый?!
Главное, что бы конечный итог был определенным и вас не мучил вопрос использования исключений.

Нет не должен.
В ряде случаев приложение вообще не может никак повлиять на твои нештатные ситуации.

Твоя задача поймать и корректно обработать все нештатные ситуации.



Это не зависит от исключения или статуса функции.

Работа с исключениями, как уже было сказано выше, это просто другая идеология обработки ошибок и прочего.

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

Пример:

У нас есть тридцать три места в которых возможно происхождение ошибки. У всех этих мест стой код ошибки, т.е. имеем 33 кода ошибки. Пусть у нас все ошибки обрабатываются одним способом, а именно выводом сообщения "извините такой страницы нет". Никаких сложностей при реализации.

Время идет и количество мест потенциального возникновения ошибки возросло до 100, а кодов ошибок до 50. Вроде бы ничего страшного. Только вот и количество вариантов сообщения возросло до 5 и распределяется на эти 50 кодов. Вот в таком случае нам и помогут исключения.
Вместо 50 кодов заводим 50 вариантов исключения. И если нам требуется поменять логику обработки какого то из них, идем в обработчик исключений и изменяем только его, не затрагивая остальной код. В традиционном подходе же придется изменить все места вывода сообщения об ощипке. Либо использовать обертку внутри которого будет свитч, т.е. по сути эмулировать работу исключений.

Попробую вечером это кодом показать.

Это сообщение отредактировал(а) krundetz - 4.7.2012, 17:36

Что за глупость? Я максимально обязан "отловить" места возможных ошибок. И если что-то не сработало, то приложение должно быть остановлено. Зачем нужна пользователю пустая страница если возникла ошибка при обращении к базе и зачем ему дальше работать? Пользователю нужен результат.

krundetz, до появления исключений было простое решение. Создаём класс для обработки ошибок. И так же при возникновении определённой ошибки посылаем определённый код в этот класс и получаем "нужную реакцию". Появление исключений сделало тоже самое, соответственно расширив функционал и приведя всё к "стандартному" виду.

Как я выше писал, что если приложение работало со своим обработчиком ошибок, то внедрение механизма исключений по крайней мере лишнее время, а следственно и деньги.. Для новых разработок, да, этот механизм позволит не изобретать велосипед. Хотя опять же всё зависит от размеров проекта, для сайта из пяти страниц это будут огромные трудозатраты

Добавлено через 3 минуты и 45 секунд
ну есть совсем простой вариант, просто пользоваться "@"  

Это сообщение отредактировал(а) Gold Dragon - 5.7.2012, 07:27

Gold Dragon, внимательно читаем свой горячечный бред.



У вас вылетела сетевая карта на сервере БД.
Нештатная ситуация? Да!
Вы можете от нее избавиться благодаря программисту? Нет!

Все что может сделать программист - это поймать любую подобную ситуацию корректно обработать

Fortop, у меня нет проблем ни со зрением, ни с психикой, так что не нужно выделять "особо умные мысли". Я способен нормально понять логику в предложениях и осознать смысл сказанного.

еперь про "сетевую карту".. А причём тут вообще это??? Мы говорим о программе, а не о железе(!). И научись не продвигать свою мысль, а прислушиваться к чужим. По форуму я вижу только твои рассуждения, но ни разу пример кода. 

Ну и про исключения.. Если внимательно почитать тему, то давно уже все пришли к общему (в той или иной степени) мнению. Ответь пожалуйста, как ты решал эти проблемы когда не было PHP5?

Это сообщение отредактировал(а) Gold Dragon - 5.7.2012, 12:54

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

нет, смысл есть. Т.е. в PHP5 разработчики заложили достаточно (или относительно) продуманный интерфейс для "отлова ошибок". И для разработки больших проектов этот механизм желательно задействовать. Конечно нет смысла это делать для существующих проектов, т.к. это достаточно большие трудозатраты. И так же нет смысла делать для "сайтов-визиток" 

Да,  с сетевой картой это не нештатная ситуация, это катастрофа. В контексте темы она не вписывается. 

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

Нет, не совсем.
Это другая парадигма безопасного программирования, чем то похожа ситуация противопоставления функциональной парадигмы программирования - парадигме ООП.
PHP язык развивающийся с процедурного, поэтому как говорится каждому методу своё место.  
В больших проектах больше ошибок, поэтому логичней поставить развитую структуру отлова потока ошибок, при чём чем более разнообразных предметных концепций тем больше стоит внедрять логику исключений. 
Хотя если используешь парадигму исключений, я бы использовал бы и далее да же на сайте визитке. Написания кода в этом случае почти не увеличивается, почти - это только определение самих классов (типов) ошибок и то минимум пустых. Хммм ... я бы да же сказал что парадигма статусов ошибок что исключений в написании кода практически одинакова. Так что это кто как любит: кто копчёную колбасу, а кто и грибочки под водочку 

Это сообщение отредактировал(а) Sentox - 5.7.2012, 13:59

вот маленький пример

или так

ну и чем это хуже исключений  И просто и красиво

Это сообщение отредактировал(а) Gold Dragon - 5.7.2012, 14:21

Тем, что у вас нет автоматического отлова аварийной ситуации. Все вызовы Error инициированы вами в ручном режиме. Это предвиденные вами ошибки. Вы же понимаете, что это далеко не все варианты аварийного развития событий.

Пример на псевдокоде :



Теперь предположим, что по неведомым причинам у вас каждый раз, сразу же после соединения срывается коннект к базе. Что в итоге получим? В итоге получаем Error('Ошибка при запросе'). Что начинаем делать? Я бы начал тщательно и внимательно анализировать SQL запрос. А это в данной ситуации - действие неверное, как следствие трата времени, сил, нервов и т.п.
Пример далек от идеала, но определенную ясность, я думаю, внесет.





Это сообщение отредактировал(а) Zerstroer - 5.7.2012, 14:34

Второй не красивый, первый лучше.
Не красив тем что обязывает знать о кодах для определённых ошибок. В этом случает DelenieNaNol более информативно, а если так showMessageDelenieNaNol() ещё информативней, но опять же если требуется большей информации: имя файла, строка ошибки, трассировка для ошибки (очень полезных механизм) и добавление своих данных (например сообщение об ошибке изменить или добавить дополнительную информацию) и тем более общей функциональности тогда:


Вот код с исключением, код конечно не выявляет все стороны исключений но всё же :  


Если убрать коментарии написания кода меньше.
И при написании кода я концентрировался на нормальном пути работы алгоритма, а в точках ошибок только ставил псевдокод. В данном случае конечно это не особо видно, но каогда у тебя сложный алгоритм обработка ошибок отвлекает. Это конечно можно делать и без исключений но в данном случае все типы исключений обрабатываются одинаково и в одном месте. Так же можно применять по типам ошибок свои обработчики. И что ещё полезней, при генерации ВЫ можете совершенно не перехватывать в этой функции ошибки а дать возможность вызывающим это сделать, что даёт возможность более удобно расслаивать систему. 

Это сообщение отредактировал(а) Sentox - 5.7.2012, 15:22

бездоказательно.
А вот наличие других проблем у вас вполне видно по вашей же цитате ниже.


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


P.S.

Архивы почитайте 
В том числе и на ваши же вопросы.
Тот факт что вы не понимаете написанного не отменяет его наличия 

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

ну или даже так

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

Это сообщение отредактировал(а) Sentox - 5.7.2012, 16:28

Gold Dragon, в совокупности с наследованием, исключения предоставляют мощную систему для работы проекта. Поясню на примере псевдокода:

Gold Dragon, исключения с одной стороны, и любые другие средства, включая Ваши красивые классы, с другой - разные подходы к обработке ошибок. Исключения - помощь языка в декомпозиции при обработке ошибок. Написав кучу классов вы, возможно, достигнете некоторого уровня декомпозиции, но не настолько, как с использованием исключений. Результат отказа от исключений - больше работы, но менее управляемый код.
Это в теории. На практике надо от параметров Вашего проекта отталкиваться, что бы принять решение.
Не ругайтесь, а попробуйте понять. Мы терпеливые, объясним столько, сколько потребуется.

Fortop ведь тут прав, но он не обругал Вас, а хотел стимулировать Вашу мысль   

Тут ты не прав. программисты под "конкретный движок" должны знать не только коды ошибок, но все интерфейсы (на то они и пишутся). Т.е. программисты как то должны знать API 

да(!) Просто складывается впечатление что разработчики PHP хотят угнаться за ..... теми же СИшниками или Дельфистами... Хотя... вернувшись к Делфи я понял что PHP имеет очень много "вкусностей" которых очень не хватает Делфи..

Fortop хороший человек  и тем более я не в том возрасте чтобы меня можно обругать... Но я (так как очень закостенел) не люблю когда говорят что я не прав... Я люблю доказательства.. и очень сильные.. Я юрист и слова это большое оружие, но только для "обывателей"  Я же тут где-то сказал что обоснуйте мне что "ИСКЛЮЧЕНИЯ ЭТО ОЧЕНЬ КРОТУ"  И вообще, Fortop хороший человек, хоть кто-то против, хоть с кем то можно поспорить. Хотя всё равно лучшее доказательство - это код примера ;)

Aliance, даже по другому и не рассматриваю ;) Но ведь всё равно тут я не увидел явных фанатов исключений 

потому что фанатизм — не лучший подход.
преимущества расписали. не хочешь использовать - не используй.

кстати,... "хреновый вы программист" - это как?  Могу с ходу охаить любой код даже самого великого программера  И, кстати, а как это мерить? в рублях? в количестве проектов? ..  Я 12 лет создаю сайты.. и постоянно учусь... хочу постоянно знать все новые технологии... конечно не угнаться за всем сразу...

Добавлено через 1 минуту и 51 секунду
skyboy, хочу использовать. но хочу понять и преимущества 

PS
согласен, фанатизм это болезнь... 

Я не о том знать или нет (здесь безоговрочно что следует), смысл в том что код 1002 ничего осмысленного не несёт, а если он будет описан например константой мало того что будет читабельный код, так же его можно будет изменить легко, только в одном месте определения константы.
В исключениях коды или описательные константы заменют типы (классы), при чём подтипы могут наследовать от других  так сказать "кодов" функциональность или расширять её, например использование другого текста или добавления своего, что очень затруднительно со скалярными величинами.

Это сообщение отредактировал(а) Sentox - 5.7.2012, 22:55

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

Не обязательно, их можно по дефолту определить как свойство класса и использовать не передавая сообщения.
Например:




а ещё шире


Это сообщение отредактировал(а) Sentox - 5.7.2012, 23:04

ключевое слово - обобщение

Добавлено через 7 минут и 9 секунд

Использование исключений никак не связано с сообщениями об ошибках. Сообщения - лишь один из видов реакции на.
Пример: если доступен файл А, надо использовать его, в противном случае используется файл B. Вызывающая подсистема вообще не в курсе, какой файл используется, она работает с дескриптором открытого файла. Файл B всегда доступен (допустим, это стандартный поток).
Проблема в том, что файлы А и В открываются на совершенно разных уровнях приложения, обычным if не обойтись.
Вот тут и помогут исключения, что бы не тащить информацию об открытом файле снизу вверх.

baldina, Исключения подразумевают, ( обычно, а не в php  )  3 реакции на исключительную ситуацию - продолжить, пропустить операцию и  повторить операцию еще раз. То есть, в принципе - это своеобразный callback, совместно с goto В PHP от возможности повторить операцию напрочь отказались, вероятно потому, что многие стандартные функции php не генерят исключений, а выводят коды ошибок. Tо есть в PHP исключения, по сравнению с обычным их применением, выродились в простую реакцию на исключительные события. Пользой осталась только возможность обработки самих таких событий в другом месте.

так что фраза 
 

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

я имел в виду что исключения возбуждаются и обрабатываются вне вызывающей подсистемы, в сервисной, но на разных уровнях. вызывающая (в отношении А и В) работает без исключений.
и я не имел в виду только php (хотя в php модель исключений не слишком отличается от java или c++)

на исключительную ситуацию есть 2 разумные реакции - попробовать что-то сделать или аварийно завершиться

а где не отказались? ;-)

Хм... Действительно, это я ступил.     Только в бейсике от MS можно вернуться в то-же место и повторить все заново. Мне казалось, что такая удобная фенечка откуда-то стырена... Оказалось - нет, оригинальная бейсиковая фича... Удобная, кстати, фенечка. Мне ее не хватало местами    
В остальных доступных мне языках - нельзя. Так что php тут не оригинален, просто так оно и сделано, как везде.

Все равно пример остался непонят.
Есть некий сервис - линейная работа с неким файлом. С точки зрения вызывающей стороны - процедура с параметром - хандлом файла. Вызывающая сторона смотрит на файлы A и B и делает вызов с одним или другим параметром. В каком месте тут присутствуют исключения?

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

открытие, существование ....

baldina, имеет ввиду что исключения генерируются в функции (подсистеме) и не обрабатываются и не перехватываются самой функцией (подсистемой)


Если я правильно понял ситуацию 

Это сообщение отредактировал(а) Sentox - 7.7.2012, 00:04

а сколько народа реально применяет Исключения в своих проектах? Я пока нет  но скорее всего в новых буду. И даже не потому что это "лучше", а потому что наверное "это правильно"

ну почему же везде... скорее, под влиянием c++, а в с++ когда создавалась модель исключений было принято решение "без продолжений", потому что это сложно реализуется, нужно крайне редко, и в этом случае можно смоделировать.

да

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

возможны следующие исключительные ситуации:
1. бд недоступна
2. пользователь запрашивает несуществующий файл
3. доступ к файлу запрещен. этот случай - часть нашей задачи, но в рамках модели "открыть-проверить-прочитать" его удобно представлять как исключительную ситуацию
теперь поглядим, как этот код будет выглядеть с обработкой исключений и без нее, с кодами возврата.
без исключений:


какой вам кажется проще для понимания и расширения? и это простейший пример, без наследования и т.п.

надо делать только то, что понимаешь. есть лишь один довод использовать какую-то фичу впрок: если она улучшает декомпозицию проекта, т.е. делает проект более приспособленным к расширению. 

Ещё к примеру baldina, добавлю: это удобочитаемо, потому как по Мартину программист существо социальное и код легче читать, а не просто что бы он работал (меня умиляют такие программисты, которые говорят "Ну оно ж работает!"), и одно из самых главных качеств легко ставится на тесты допустим PHPUnit.
Если поставить на тесты первый пример, то придётся на каждую ошибку задавать обработку-тест что так же повышает сложность поддержки тестового кода, а мы как раз должны использовать тесты с максисмально простым кодом, для лучшей поддержки.

Это сообщение отредактировал(а) Sentox - 9.7.2012, 11:22

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

 ровно столько же, сколько и не применяет.

 нет никакого "правильно" и "не правильно", объективно оценивайте проект и принимайте адекватное решение о целесообразности использования исключений. Код должен стремиться к очевидности, в первую очередь.

Zerstroer,


Привёл одну из сторон удобства применения исключений. В реальности удобств применений гораздо больше 

Он привел очень наглядный и истинно канонiчный пример "Вот вам без исключений, двоечники, вот вам - с исключениями, оцените разницу".  Лично - огорчусь за baldina, если он пример взял не из своей головы, а из учебника.