PHP Lang
  1. PHP Lang
  3. trigger_error против исключения броска
Intereting Posts
Динамически рассчитать цену продукта на основе значений настраиваемых полей при добавлении в корзину Преобразование документа Word в полезный HTML в PHP DOMDocument appendXML со специальными символами отправлять электронную почту с вложением в php без сохранения файла на веб-сервере PHP SFTP Простая загрузка файлов завиток следит за ошибкой местоположения MySQL ORDER BY IN () проверка электронной почты, а затем действие сценария для реагирования на sms-сообщение Не удалось найти перенос сокетов «ssl» – вы забыли включить его при настройке PHP? Компиляция PHP с поддержкой GD и libjpeg Определение иерархии классов объекта во время выполнения Может ли объект JSON, возвращаемый PHP, содержать объект даты mysqli_num_rows () ожидает, что параметр 1 будет mysqli_result, объект Форма входа в PHP с формой HTML Как установить заголовок по умолчанию в Guzzle?

trigger_error против исключения броска

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

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

Я обновляю эту библиотеку , этот вопрос касается метода send , но достаточно общий. Это мои рассуждения:

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

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

Я локомотив? Разве это не нужно и раздражает, или это имеет смысл?

Подавить ошибку с @ operator в PHPБелый экран смерти!Функция псевдонима PHPБлоки try-catch PHP: могут ли они улавливать недопустимые типы аргументов?Как избежать кавычек при вставке в базу данных с помощью PHP

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

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

Поскольку все мои ошибки PHP (примечание: не исключения, но предупреждения, уведомления, смертельные и т. Д.) Регистрируются в процессе производства, я думаю, что trigger_error – это удобный способ получить материал в указанном журнале.

Вот пример:

Я использую HTTP-клиент для доступа к API, который мы интегрируем. Разумеется, библиотека, которую я использую, является объектно-ориентированным PHP и поэтому сильно использует исключения. Я здесь делаю разные вещи, и я надеюсь, что этот пример имеет смысл:

  1. Клиентская библиотека HTTP генерирует исключение, когда фактический запрос не удался – например, из-за проблемы с подключением, такой как тайм-аут и т. Д. Конечно, я поймаю эту ошибку, но я не подниму ее пользователю. Моя обертка возвращает false, и это равно: «Временная проблема». в интерфейсе.
  2. В моем блоке catch() я использую trigger_error() для регистрации отладочной информации о фактической ошибке соединения. Так как я получил error_log = syslog в моем php.ini вся эта информация отправляется в syslog и в конечном итоге в мой мастер журнала.

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

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