Pull to refresh
62
kotiara@kotiara

User

7
Subscribers
Send message
Да вы правы, насчет примера с WeAreDoomedException. Это еще один антипаттерн работы с исключениями. В таких случаях надо хотя бы логер ставить.
Пересказывать мануал в статье бессмыслено. Я хотел рассказать то, чего там нет.
7. Хорошо давайте представим себе код, который работает без исключений в данном примере. У нас 2 варианта, либо кусок кода который отвечает за проверку баланса (а так же открывает транзакцию к бд, после считывания баланса получает лок на таблицу) держать в контролере, либо сделать кастомный механизм передачи ошибок из метода в контролер. Второй вариант мне не нравится, так как у меня уже есть один метод обработки ошибок — исключения. Если же хранить весь код в контролере, то получается размазывание модели по контролеру.
8. Как быть, если мне действительно нужно передать, вот такое сложное сообщение? Вариант написать код на if else и передать любой другой объект (ассоциативный массив) с этим сообщением. Те же яйца, только в профиль.
При правильном использовании try catch код становится более читабельным, чем при использовании if else. При if else обычно получается лесенка, и всякие else условия отвлекают от основной логики. При exception код «выпрамляется», можно четко увидеть позитивную ветку логики. Вот для сравнения два примера: код на if else, код на exception. И совсем экстремальный вариант при преобразовании ошибок в exception, не скажу что это правильный вариант, так как это определный magic — все таки разработчик должен точно знать и обрабатывать все ошибочные ситуации.
Насчет замыливания глаза, это для каждого по своему. А copy-paste в первую очередь зависит от квалификации и ответсвености разработчика. И архитектура не может ни стимулировать ни предотвратить этого.
Да такой подход предполагает внимательную обработку исключений. В месте где обработка критична нужно будет обработать все исключения (вплоть до верхнеуровневого — Exception) пример кода.
Где обработка менее критична, можно оставить это на откуп глобального обработчика — try...catch на самом верхнем уровне в бутсрапе или exceptionHandler.
Такой подход не означает, что не нужно делать проверки в коде, он даже стимулирует — потому, что вместо ворнинга, который можно игнорить получаешь исключение.
Exception применяются для ошибок которые можно обработать на програмном уровне. Фактически все те, которые можно было бы обойти дополнительными проверками, например file_exists() перед чтением файла или array_key_exists для неверного индекса массива.
я думаю самый простой вариант — xDebug, FireFox и easyXdebug
разница между функцией и объектом, в том что объект еще может иметь состояние. Например, мне нужно реализовать формат вывода ошибок для SOAP сервера, для того чтобы вернуть SoapFault мне нужен инстанс SoapServer. В класс инстанс SoapServer можно передать, например, как параметр конструктора (см. код). А как это сделать для функции? Через глобальную переменую…
Если вас и этот аргумент не убедил, тогда я прошу помощь зала
error_log($messge."\n", 3, 'path/to/my-errors.log') пишет туда куда надо
А какие XML данные вы собираетесь писать при фатале, которых нет в стандартных логах вебсервера и php?
error_log умеет
Спасибо за ссылку. Может возьму оттуда идеи. Смущаает следующее (то что сразу заметил):
  1. 1. на главной написано «Just 20kb of 100% OOP source code», а настройки сделаны через глобальные константы;
  2. 2. коду два года (так написано на главной), а в коде есть тудушки с элементарными вещами, за такое время можно было додлеать
это не религия, это легкая поддержка кода, читаемость, reusablity, encapsulation, modularity и многое другое.
Я считаю, что "PHP Notice: Use of undefined constant myvar - assumed 'myvar'" и "PHP Warning: mysql_connect(): [2002] A connection attempt failed" вполне достойны для того, чтобы бросить исключение.
Хотя у меня в классе есть настройка, которая говорит какие ошибки превращать в исключения. По умолчанию E_ALL. Те ошибки которые не будут превращаться в исключения будут залогированы с флагом lowPriorityError.
С моим решением можно использовать FirePhp (он же WildFire). Для этого нужно создать класс exceptionHandlerOutputFirephp и экземпляр этого класса передать как параметр для setupHandlers. Могу попозже выложить код такого класса.
2. пользователю надо выдавать нормальную страничку с сообщением об ошибке. с навигацией, поиском и прочими плюшками.
Я только за.
3. через обычные функции получится не ООП код. А я предпочитаю ООП
В статье сами обработчики не описываются. Можете посмотреть в коде (ссылка в конце статьи). Файл ExceptionHandlerClass.php статические методы *handler().
Это не стиль Явы или Си-шарпа это стиль ООП. Я считаю, что ООП код гораздо проще поддерживать, он гораздо компактней и понятней. Но это дело вкуса.
Кто-то настроение испортил?
  1. 1. Про фатальные ошибки обсудили в комментариях выше
  2. 2. Я обрабатываю только необработанные исключения, можно обрабатывать и на уровне приложения; в bootsrap файле может быть что-то типа
    try{
        myApplication::dispatch();
    } catch(Exception $e){
       //обработка
    }
    

    Я предложил один из вариантов...
  3. 3. Сакральный смысл — сделать расширяемое решение. Груда классов вряд ли понадобится — достаточно будет 1 или 2 кастомных обработчика (зависит от потребностей приложения)
Спасибо. Обязательно посмотрю.
Я тоже думал о подобном решении. Только кроме логирования я хочу еще и правильный ответ выдать. Мой вариант писать в header особую метку. Если метки нет (значит скрипт не правильно отработал), то reverse proxy отдаст 500 ошибку и залогирует событие. Это может пригодится при автоматическом тестировании.
Баг в ПХП из-за которого приходится так извращатся bugs.php.net/bug.php?id=50921
Спасибо за подсказку. Решение до гениальности простое — register_shutdown_function();
Учту в следующей версии библиотеки.

Information

Rating
Does not participate
Registered
Activity