Какова рекомендуемая настройка error_reporting() для разработки?А как насчет E_STRICT?

StackOverflow https://stackoverflow.com/questions/74847

  •  09-06-2019
  •  | 
  •  

Вопрос

Обычно я использую E_ALL чтобы увидеть что-нибудь, что PHP может сказать о моем коде, чтобы попытаться улучшить его.

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

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

Поэтому мне интересно, использую ли я лучшее error_reporting уровень с E_ALL или это будет вместе с E_STRICT будь лучшим?Или есть какая-то другая комбинация, которую мне еще предстоит изучить?

Это было полезно?

Решение

В PHP 5 все, что описано E_STRICT не охвачены E_ALL, поэтому, чтобы получить максимум информации, нужно их объединить:

 error_reporting(E_ALL | E_STRICT);

В PHP 5.4 E_STRICT будет включен в E_ALL, поэтому вы можете использовать просто E_ALL.

Вы также можете использовать

error_reporting(-1);

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

error_reporting(~0);

Другие советы

Используйте следующее в php.ini:

error_reporting = E_ALL | E_STRICT

Также вам следует установить Xdebug, он может выделить ваши ошибки яркими цветами и распечатать полезную подробную информацию.

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

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

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

http://php.net/error_reporting

E_ALL | E_STRICT для разработки на PHP до версии 5.2.0.

5.2 представляет E_RECOVERABLE_ERROR и 5.3 представляет E_DEPRECATED и E_USER_DEPRECATED.Вероятно, вы захотите включить их, если используете одну из этих версий.

Если вы хотите использовать магические числа, вы можете просто установить error_reporting значение до некоторого довольно высокого значения 2^n-1 - сказать, 16777215, и это на самом деле просто включило бы все биты между 1..n.Но я не думаю, что использование магических чисел — хорошая идея...

На мой взгляд, PHP немного упустил возможность, E_ALL на самом деле не все.Но, видимо, это будет исправлено в PHP 6...

В новых версиях PHP E_ALL включает больше классов ошибок.Начиная с PHP 5.3, E_ALL включает в себя все кроме Э_СТРИКТ.В PHP 6 предположительно будет даже это.Это хорошая подсказка:лучше видеть больше сообщений об ошибках, чем меньше.

Что включено в E_ALL, описано в Предопределенные константы PHP страницу в онлайн-руководстве.

Лично я думаю, что использование E_STRICT не имеет большого значения.Это определенно не повредит вам, тем более что это может помешать вам писать сценарии, которые с небольшой вероятностью могут быть сломаны в будущих версиях PHP.С другой стороны, в некоторых случаях строгие сообщения могут быть слишком шумными, особенно если вы спешите.Я предлагаю вам включить его по умолчанию и выключить, когда он начнет раздражать.

Вы можете использовать error_reporting = -1
Он всегда будет состоять из всех битов (даже если их нет в E_ALL)

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

  1. Согласно руководству, большинство E_STRICT ошибки генерируются во время компиляции, а не во время выполнения.Если вы увеличиваете уровень ошибки до E_ALL внутри вашего кода (а не через php.ini), возможно, вы никогда не увидите E_STRICT ошибки все равно.
  2. E_STRICT содержится внутри E_ALL под PHP 6, но не под PHP 5.Если вы обновите свой сервер до PHP6 и у вас есть E_ALL настроенный, как описано в пункте 1 выше, вы начнете видеть E_STRICT ошибки, не требуя каких-либо дополнительных изменений с вашей стороны.

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

В Zend Studio for Eclipse эта функция включена по умолчанию, и с тех пор, как я начал ее использовать, она мне помогает. много ловить ошибки до того, как они произойдут.

Например, у меня был фрагмент кода, в котором я кэшировал некоторые данные в $GLOBALS переменная, но я случайно написал $_GLOBALS вместо.Данные никогда не кэшировались, и я бы никогда не узнал, если бы Зенд не сказал мне:«Эй, это $_GLOBALS штука появляется только один раз, это может быть ошибкой».

ini_set("display_errors","2");ОШИБКА_ОТЧЕТ (E_ALL);

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top