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

Question

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

Способы установки максимального уровня:

PHP <5.4: </p>

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 и настраиваемый класс исключений для перезаписи файла и строки

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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