Какова рекомендуемая настройка error_reporting() для разработки?А как насчет E_STRICT?
-
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
держать в уме:
- Согласно руководству, большинство
E_STRICT
ошибки генерируются во время компиляции, а не во время выполнения.Если вы увеличиваете уровень ошибки доE_ALL
внутри вашего кода (а не через php.ini), возможно, вы никогда не увидитеE_STRICT
ошибки все равно. 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);