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

Question

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

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

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

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

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

Answer 2

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

error_reporting = E_ALL | E_STRICT

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

ini_set ( "display_errors", "2"); Error_reporting (E_ALL); * * 1 001