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

Нет, не совсем.
Это другая парадигма безопасного программирования, чем то похожа ситуация противопоставления функциональной парадигмы программирования - парадигме ООП.
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, конечно ты прав.. но это уже конкретный подход к вопросу...  В любом случае мы же в исключениях должны прописывать как минимум сообщения об ошибках, а значит программер должен знать и их