¿Cuál es la configuración error_reporting() recomendada para el desarrollo?¿Qué pasa con E_STRICT?

Question

Normalmente uso E_ALL para ver cualquier cosa que PHP pueda decir sobre mi código para intentar mejorarlo.

Acabo de notar un error constante. E_STRICT, pero nunca lo he usado ni oído hablar de él, ¿es esta una buena configuración para usar en el desarrollo?El manual dice:

Avisos en tiempo de ejecución.Habilite para que PHP sugiera cambios en su código, lo que garantizará la mejor interoperabilidad y compatibilidad futura de su código.

Entonces me pregunto si estoy usando el mejor error_reporting a ras de E_ALL o eso junto con E_STRICT ¿sé el mejor?¿O hay alguna otra combinación que todavía tengo que aprender?

Answer 1

En PHP 5, las cosas cubiertas por E_STRICT no están cubiertos por E_ALL, por lo que para obtener la mayor cantidad de información, debes combinarlos:

 error_reporting(E_ALL | E_STRICT);

En PHP 5.4, E_STRICT será incluido en E_ALL, por lo que puedes usar solo E_ALL.

También puedes usar

error_reporting(-1);

que siempre permitirá todo errores.Lo cual es más semánticamente correcto como:

error_reporting(~0);

Answer 2

Utilice lo siguiente en php.ini:

error_reporting = E_ALL | E_STRICT

También deberías instalar xdebug, puede resaltar sus errores con colores brillantes y cegadores e imprimir información detallada útil.

Nunca dejes ningún error o aviso en tu código, incluso si es inofensivo.

Answer 3

En mi opinión, cuanto más alto establezca el nivel de informe de errores en la fase de desarrollo, mejor.

En un entorno en vivo, desea un conjunto ligeramente (pero sólo ligeramente) reducido, pero desea que se registren en algún lugar donde el usuario no pueda verlos (prefiero syslog).

http://php.net/error_reporting

E_ALL | E_STRICT para desarrollo con PHP anterior a 5.2.0.

5.2 presenta E_RECOVERABLE_ERROR y 5.3 introduce E_DEPRECATED y E_USER_DEPRECATED.Probablemente querrás activarlos si estás ejecutando una de esas versiones.

Si quisieras usar números mágicos, simplemente podrías configurar el error_reporting valor a algún valor bastante alto de 2^n-1 - decir, 16777215, y eso realmente activaría todos los bits entre 1..n.Pero no creo que usar números mágicos sea una buena idea...

En mi opinión, PHP ha dejado caer un poco la pelota al tener E_ALL Realmente no es todo.Pero aparentemente se va a solucionar en PHP 6...

Answer 4

En versiones más nuevas de PHP, E_ALL incluye más clases de errores.Desde PHP 5.3, E_ALL incluye todo excepto E_ESTRICT.En PHP 6 supuestamente incluirá incluso eso.Esta es una buena pista:Es mejor ver más mensajes de error que menos.

Lo que se incluye en E_ALL está documentado en el Constantes predefinidas de PHP página del manual en línea.

Personalmente, creo que no importa mucho si usas E_STRICT.Ciertamente no le hará daño, especialmente porque puede impedirle escribir scripts que tienen una pequeña posibilidad de fallar en futuras versiones de PHP.Por otro lado, en algunos casos los mensajes estrictos pueden resultar demasiado ruidosos, quizás especialmente si tienes prisa.Le sugiero que lo active de forma predeterminada y lo desactive cuando se vuelva molesto.

Answer 5

Puedes utilizar error_reporting = -1
Siempre estará formado por todos los bits (incluso si no están en E_ALL)

Answer 6

Dependiendo de sus planes de soporte a largo plazo para este código, la depuración con E_STRICT enable puede ayudar a que su código siga funcionando en un futuro lejano, pero probablemente sea excesivo para el uso diario.Hay dos cosas importantes acerca de E_STRICT a tener en cuenta:

1. Según el manual, mayoría E_STRICT Los errores se generan en tiempo de compilación, no en tiempo de ejecución.Si está aumentando el nivel de error a E_ALL dentro de su código (y no a través de php.ini), es posible que nunca veas E_STRICT errores de todos modos.
2. E_STRICT está contenido dentro E_ALL bajo PHP 6, pero no bajo PHP 5.Si actualiza su servidor a PHP6 y tiene E_ALL configurado como se describe en el punto 1 anterior, comenzará a ver E_STRICT errores sin requerir ningún cambio adicional de su parte.

Answer 7

No hablando estrictamente de error_reporting, yo fuertemente Sugiera el uso de cualquier IDE que muestre automáticamente errores de análisis y fallas comunes (por ejemplo, asignación en condición).

Zend Studio para Eclipse tiene esta función habilitada de forma predeterminada y desde que comencé a usarla me ha ayudado. mucho detectar errores antes de que ocurran.

Por ejemplo, tenía este fragmento de código donde estaba almacenando en caché algunos datos en el $GLOBALS variable, pero sin darme cuenta escribí $_GLOBALS en cambio.Los datos nunca se almacenaron en caché y nunca lo sabría si Zend no me lo dijera:"Oye, esto $_GLOBALS aparece sólo una vez, eso podría ser un error".

Answer 8

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