¿Por qué no utilizar el nivel de informe de error más alto en PHP?

Question

Quiero que expliques por qué alguien no debería usar el nivel de informe de error más alto posible en PHP.

formas de configurar más alto nivel:

PHP < 5.4:

error_reporting(E_ALL | E_STRICT); 

PHP> = 5.4:

error_reporting(E_ALL); 

PHP todas las versiones (como se recomienda para config files) :

error_reporting(2147483647); 

PHP todas las versiones (mi config, -1 contendrán todos los errores y es fácil de recordar)

error_reporting(-1); 

Mis experiencias:

• no hay ninguna razón para la baja niveles de informes
• nunca utilizado el error control operator
• uso para convertir todos los errores a través de excepciones set_error_handler y la clase de excepción personalizada para sobrescribir el archivo y la línea

Answer 1

yo personalmente prefiero a codificar en el más alto nivel de informe de errores y la solución de todos los avisos generados por el código. Sin embargo, puedo imaginar un par de razones por las cuales es posible que desee trabajar en un nivel inferior:

1. Es posible que esté trabajando con el código heredado que emite muchas advertencias. Si el código funciona correctamente, esto no es un problema, pero el "ruido" puede distraer y evitar que veas los problemas reales. En esta situación, puede ser conveniente reducir el nivel de informe de error.
2. En un entorno de producción, es posible que desee registrar solo los errores. Esto tiene dos ventajas, significa que los registros de errores solo contienen problemas críticos que requieren atención, y ahorrará espacio en disco (y reducirá las E/S del disco).

Fuera de tema a un lado: En el entorno de producción se debe ejecutar "display_errors = Off" y "error_logging = On" para evitar que los usuarios vean los errores de PHP (que pueden contener información sensible propiedades de conexión por ejemplo, la base de datos), y recoger un registro de errores a medida que ocurren. Por lo tanto, su nivel de error de producción y la configuración relacionada pueden ser diferentes a los que prefiere ejecutar en desarrollo.

Answer 2

Creo que no hay una buena razón, excepto tal vez lo que Jim dice en su primer punto, que ejecuta un código heredado que no puede o no va a cambiar.

Lo más seguro es que lo ejecute al más alto nivel durante el desarrollo y borre todas las advertencias y avisos a menos que tenga una buena razón para no hacerlo.

Si tiene una buena razón para no reparar un aviso durante el desarrollo, debe documentarlo y utilizar el operador de error de contorl para evitar saturar los registros.

Answer 3

Además de los puntos de Jim, siempre recomendaría la codificación con el más alto nivel de informes de errores, ya que debería ofrecerle una mejor portabilidad y (cuestionablemente) un mejor rendimiento.

Answer 4

Bien desde un administrador de sistemas POV ... a veces no hay nada que puedas hacer con respecto al código heredado o nuevo. Algunos desarrolladores no depuran correctamente y un gerente te mirará raro si pierdes el tiempo de alguien con algo que realmente no importa (no estoy seguro si esto molestará a alguien, pero si el resultado es el mismo antes y después, entonces realmente no importa). Por mi parte, estoy muy contento de poder deshabilitar los avisos y concentrarme en cualquier problema real.

Además, esto es solo una foto en la oscuridad, pero tal vez hay alguna manera de hacer algo un poco elegante con esto en términos de depuración mediante el uso de llamadas error_log().