Какова рекомендуемая настройка отчета об ошибках () для разработки? Как насчет E STRICT?

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

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

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

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

28
error-reporting php

8 ответов

в 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);
44

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

error_reporting = E_ALL | E_STRICT

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

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

10

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

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

5

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

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

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

2

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

2

в зависимости от ваших долгосрочных планов поддержки для данного кода, отладка с 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 ошибки без каких-либо дополнительных изменений с вашей стороны.
1

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

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

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

0

безопасность("что display_errors","2"); ПРЕДНАЗНАЧЕННЫХ(СОСТАВ E_ALL);

-1