trigger_error против выдачи исключений

Question

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

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

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

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

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

I loco?Это ненужно и раздражает, или имеет смысл?

Answer 1

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

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

Вот пример:

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

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

Answer 2

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

Answer 3

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

Редактировать: этот пример основан на веб-приложениях; То же самое можно сказать о любом фрагменте переменных данных в неуправляемом приложении.