Почему бы не использовать высокий уровень отчетности об ошибках в PHP?

Я хочу, чтобы вы приводили причины, почему кто-то не должен использовать максимально возможный уровень отчетности об ошибках в PHP?

Способы установить самый высокий уровень:

PHP < 5,4:

error_reporting(E_ALL | E_STRICT);

PHP >= 5.4:

error_reporting(E_ALL);

PHP все версии (как рекомендовано для конфигурационных файлов):

error_reporting(2147483647);

PHP всех версий (моя конфигурация, -1 будет содержать все ошибки и легко запоминается)

error_reporting(-1);

Мой опыт:

нет причин для низких уровней отчетности
никогда не использовал оператор управления ошибками
использовать для преобразования всех ошибок в исключения с помощью set_error_handler и настраиваемого класса исключений для перезаписи файла и строки

Ответ 1

Я лично предпочитаю код на самом высоком уровне сообщений об ошибках и исправлять все предупреждения, сгенерированные моим кодом. Тем не менее, я могу предусмотреть несколько причин, по которым вы можете работать на более низком уровне:

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

Отключить тему: в рабочей среде вы должны запустить "display_errors = Off" и "error_logging = On", чтобы пользователи не могли видеть ошибки PHP (которые могут содержать конфиденциальную информацию, например, свойства подключения к базе данных), и собирать журнал ошибок как они происходят. Таким образом, ваш уровень error_reporting и связанные с ним настройки могут отличаться от того, что вы предпочитаете запускать в процессе разработки.

Ответ 2

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

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

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

Ответ 3

Помимо точек Jim, я всегда предлагал кодирование с максимальным уровнем сообщений об ошибках, поскольку он должен предлагать вам лучшую переносимость и (сомнительно) лучшую производительность.

Ответ 4

Хорошо из sys admin PoV... иногда нет ничего, что можно было бы сделать с кодом-наследием или новым. Некоторые разработчики не отлаживают должным образом, и менеджер будет смотреть на вас смешно, если вы тратите время на то, что на самом деле не имеет значения (не уверен, что это кого-то расстроит, но если результат будет таким же до и после, то это не имеет большого значения). Я очень рад, что могу отключить уведомления и сосредоточиться на любых реальных проблемах.

Кроме того, это просто выстрел в темноте, но, возможно, есть какой-то способ сделать что-то малое с этим в плане отладки с помощью вызовов error_log().