Правильная обработка ошибок в PHP

Спасибо за подсказку. Решение до гениальности простое — register_shutdown_function();
Учту в следующей версии библиотеки.

Кто-то настроение испортил?

1. 1. Про фатальные ошибки обсудили в комментариях выше
2. 2. Я обрабатываю только необработанные исключения, можно обрабатывать и на уровне приложения; в bootsrap файле может быть что-то типа
   

   try{
       myApplication::dispatch();
   } catch(Exception $e){
      //обработка
   }
   

   
   Я предложил один из вариантов...
3. 3. Сакральный смысл — сделать расширяемое решение. Груда классов вряд ли понадобится — достаточно будет 1 или 2 кастомных обработчика (зависит от потребностей приложения)

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

Рискую напороться на минуса. Мне вот всегда было непонятно, что же это за «PHP-way». Т.е. вот есть куча языков и считается, что у каждого свои преимущества и недостатки, и вообще, думать надо для специфического языка по-своему. Так вот: я никогда не улавливал чего-то специфического, что предлагает PHP. Ну, точнее один момент уловил — когда нужно что-то архи-, мегапростое, то проще писать небольшой скрипт на PHP, чем мучиться с настройкой Hibernate, написанием шаблонов, контроллеров, разворачиванием всего этого дело на Tomcat. Что же насчёт больших проектов — непонятно, где преимущество подхода PHP и в чём же именно он отличается в предлагаемых средствах от Java (и вообще, нафига ему динамическая типизация). Т.е., например, я прекрасно понимаю, зачем динамическая типизация в Python и почему ряд задач на нём решается на порядок выразительнее чем на Java. А в PHP как раз для «больших» приложений начали утаскивать чуть ли не один-в-один ООП из Java, причём, похоже, динамическая типизация обеспечивает там одно «преимущество» — отсутствие необходимости аннотации типов. Оно сомнительно на фоне того, что те же Scala или F# вполне себе статически типизированы, но при том не требуют аннотации типов. А вот то, что поддержка в IDE из-за этого никакая — это, конечно, просто ужасно.

Так что я думаю, нечего пинать явистов с претензиями «вы нас не понимаете». Как мне кажется, у PHP своя ниша образовалась исторически. А может, из-за низкого порога вхождения. Но никак не потому, что PHP вносит что-то принципиально новое в мышление человека, пишущего на нём, и что мир PHP сильно отличается от Java, C# или Python.

так почему же вы этого не сделали?

Чем же он вам так не угодил? Расскажите подробнее о его недостатках перед другими языками, может тогда вы бы выглядели не так банально. Например тежи разработчики facebook с вами не согласны.

В статье сами обработчики не описываются. Можете посмотреть в коде (ссылка в конце статьи). Файл ExceptionHandlerClass.php статические методы *handler().

register_shutdown_function

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

С моим решением можно использовать FirePhp (он же WildFire). Для этого нужно создать класс exceptionHandlerOutputFirephp и экземпляр этого класса передать как параметр для setupHandlers. Могу попозже выложить код такого класса.

$firephp = FirePHP::getInstance(true);
$firephp->registerErrorHandler();
$firephp->registerExceptionHandler();

Хорошо написанная программа не notice не warning не бросает. Соответсвенно, notice говорит о том. что где-то недоработка (проблема), надо разбираться

Я считаю, что "PHP Notice: Use of undefined constant myvar - assumed 'myvar'" и "PHP Warning: mysql_connect(): [2002] A connection attempt failed" вполне достойны для того, чтобы бросить исключение.
Хотя у меня в классе есть настройка, которая говорит какие ошибки превращать в исключения. По умолчанию E_ALL. Те ошибки которые не будут превращаться в исключения будут залогированы с флагом lowPriorityError.

Она умеет писать в файл (или куда-то еще) фаталы и неотловленные исключения?

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

Спасибо за ссылку. Может возьму оттуда идеи. Смущаает следующее (то что сразу заметил):

1. 1. на главной написано «Just 20kb of 100% OOP source code», а настройки сделаны через глобальные константы;
2. 2. коду два года (так написано на главной), а в коде есть тудушки с элементарными вещами, за такое время можно было додлеать

я думаю самый простой вариант — xDebug, FireFox и easyXdebug

Да по хорошему в Aptana (eclipse) встроен клиент для XDebug и настроить это дело довольно просто.
Только желательно чтоб сервер и Aptana на одном компьютере находились (точнее — чтобы СЕРВЕР МОГ подключаться к компьютеру с Aptana — типа внешний IP или одна сеть)
mod_rewrite особого значения не имеет
На шаред хостинге скорее всего такое настроить не удастся.

Exception применяются для ошибок которые можно обработать на програмном уровне. Фактически все те, которые можно было бы обойти дополнительными проверками, например file_exists() перед чтением файла или array_key_exists для неверного индекса массива.

При правильном использовании try catch код становится более читабельным, чем при использовании if else. При if else обычно получается лесенка, и всякие else условия отвлекают от основной логики. При exception код «выпрамляется», можно четко увидеть позитивную ветку логики. Вот для сравнения два примера: код на if else, код на exception. И совсем экстремальный вариант при преобразовании ошибок в exception, не скажу что это правильный вариант, так как это определный magic — все таки разработчик должен точно знать и обрабатывать все ошибочные ситуации.
Насчет замыливания глаза, это для каждого по своему. А copy-paste в первую очередь зависит от квалификации и ответсвености разработчика. И архитектура не может ни стимулировать ни предотвратить этого.

2Offenso. Достаточно будет, если я напишу это в комментарии?
Код распространяется под «лицензией» AS-IS. Вы можете копировать, модифицировать код без указания автора и без уведомления автора. Можно использовать в коммерческих проектах. Хотя сейчас, мне этот код не кажется идеальным и я бы не использовал его в коммерческих проектах.

Мнения автора могут не совпадать с его точкой зрения (с)