¿La supresión de errores es una mala práctica?

13

En una pregunta de SO le hice aquí sobre algún código del cual no estaba seguro, alguien respondió "Por cierto, código horrible allí: usa mucho el símbolo de supresión de errores (@)"

¿Hay alguna razón por la que esto sea una mala práctica? Con cosas como:

[email protected] mysqli($db_info) or die('Database error');

, me permite mostrar solo un mensaje de error personalizado. Sin la supresión de errores, aún se mostraría el mensaje típico de PHP de:

Advertencia : mysqli :: mysqli (): php_network_getaddresses: error en getaddrinfo: no se conoce dicho host. en algunos \ archivos \ ruta en línea 6

así como 'Error de base de datos'.

¿El error de supresión de siempre es incorrecto y, de ser así, qué es lo que específicamente es malo?

Actualización: el código real que estoy usando es:

or error('Datatabase error', 'An error occurred with the database' . (($debug_mode) ? '<br />MySQL reported: <b>' . $db->error . '</b><br />Error occurred on line <b>' . __LINE__ . '</b> of <b>' . __FILE__ . '</b>' : ''))

que elimina todos los resultados anteriores y muestra un mensaje de error. Por lo tanto, el hecho de que el mensaje de error no incluya detalles sobre lo que sucedió específicamente (lo que la gente parece sugerir como una razón por la que la supresión de errores es mala) es irrelevante.

    
pregunta Community 28.11.2013 - 20:10

4 respuestas

13

Creo que estás haciendo lo correcto al suprimir el error, porque estás implementando tu propio manejo de errores.

Podría ser más fácil considerar el equivalente en, digamos, Java. Suprimir el error usando @ es análogo a tragar una excepción. El siguiente código, que es similar al tuyo, es razonable:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(Bueno, en Java, no querrías que el motor del servlet se muera, pero entiendes la idea).

Sin embargo, esto no es aceptable:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

La mayoría de la supresión de errores de PHP se hace sin cuidado, de manera análoga al último ejemplo, por lo tanto, la reacción instintiva contra su código.

    
respondido por el 200_success 28.11.2013 - 21:12
6

La supresión de errores es mala porque no solo oculta la información que ya conoce ( algo salió mal). También puede ocultar información vital para la depuración de la que no está al tanto ( what , where y por qué ).

En este ejemplo específico, " Error de base de datos " no es un mensaje de error muy bueno. Algo salió mal con el DB. No muy esclarecedor. La " Advertencia: mysqli :: mysqli (): php_network_getaddresses: getaddrinfo falló: No se conoce tal host. en algún \ archivo \ ruta en la línea 6 "es en realidad un mejor mensaje de error. Te da una ubicación y la razón del problema. Puede saltar directamente y comenzar la depuración, porque el error ya se ha localizado.

Por supuesto, los diseñadores de bibliotecas a veces tienen la tendencia de mostrar muchas advertencias irrelevantes. No sé PHP lo suficientemente bien como para saber si tiene una forma de filtrar advertencias que no le interesan. Sé que leer a través de un seguimiento de cien líneas no es muy esclarecedor. Pero la respuesta correcta a demasiada información no es reducir la cantidad de información a cero , sino filtrar partes irrelevantes en algún momento. El operador @ no tiene esta granularidad (su lema es todo o nada ) y, por lo tanto, no es una herramienta adecuada para la gestión efectiva de errores.

Hay algunos casos en los que sabe que cierto error se producirá , y que solucionar el problema real es más costoso que silenciar el mensaje (y sufrir posibles consecuencias por eso). Este podría ser el caso en una secuencia de comandos única, pero meterse los dedos en los oídos y decir " la la la " es no una respuesta profesional a los errores (potenciales) .

    
respondido por el amon 28.11.2013 - 21:11
0

Suprimir los errores es malo porque oculta el problema, que muchas veces ni siquiera conocemos y puede dar lugar a un comportamiento inesperado que puede resultar muy costoso en algunas aplicaciones críticas, por ejemplo, en aplicaciones que se utilizan en finanzas, salud y defensa. dominios.

Tampoco es una buena idea tener excepciones no controladas en el código y mostrar los mensajes de error reales al usuario, ya que puede generar problemas de seguridad, ya que los mensajes de error generalmente revelan mucho sobre su código, lo que puede ayudar a los usuarios malintencionados. piratas informáticos para manipular el sistema.

Por lo tanto, la buena práctica es manejar los errores en diferentes niveles, por ejemplo, en el nivel más alto, puede manejar el error simplemente registrando el error real y mostrando al usuario un mensaje simple y fácil de usar.

    
respondido por el Sajad Deyargaroo 28.11.2013 - 21:45
0

Sí, el operador de supresión de errores es generalmente una mala idea.

Debe administrar los informes de errores en la configuración ( php.ini ). Por lo tanto, puede elegir una configuración diferente para cada entorno (por ejemplo, dejar advertencias en desarrollo y ocultarlas en producción).

La única situación cuando se utiliza @ podría tener sentido cuando desarrollas una biblioteca para otros desarrolladores. Si elige voluntariamente hacer algo que produce una advertencia y no quiere molestar a los usuarios de su biblioteca con una advertencia que no depende de ellos, @ podría ser una solución.

No puedo pensar en ningún otro uso.

    
respondido por el lortabac 29.11.2013 - 13:34

Lea otras preguntas en las etiquetas