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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

Вот пример:

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

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

Ответ 3

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

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