Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

Ответ 1

В 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);

Ответ 2

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

error_reporting = E_ALL | E_STRICT

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

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

Ответ 3

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

В живой среде вы хотите немного (но только немного) уменьшить набор, но вы хотите, чтобы они регистрировались где-то, что они не могут быть видны пользователю (я предпочитаю 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 - say, 16777215, и это действительно просто включит все биты между 1..n. Но я не думаю, что использование магических чисел - хорошая идея...

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

Ответ 4

В новых версиях PHP E_ALL включает в себя больше классов ошибок. Начиная с PHP 5.3, E_ALL включает все, кроме E_STRICT. В PHP 6 это будет включать в себя и это. Это хороший намек: лучше видеть больше сообщений об ошибках, а не меньше.

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

ini_set ( "display_errors", "2" ); Error_reporting (E_ALL);