contador - Suprime el error con @ operator en PHP
php+= (14)
¿No hay una forma de suprimir las advertencias y los errores de php.ini? en ese caso puede depurar solo cambiando un marcador y no tratando de descubrir cuál @ está ocultando el problema.
En su opinión, ¿es siempre válido usar el operador @ para suprimir un error / advertencia en PHP mientras que usted puede estar manejando el error?
Si es así, ¿en qué circunstancias usarías esto?
Ejemplos de código son bienvenidos
Editar: Nota para los replicadores. No busco desactivar el informe de errores, pero, por ejemplo, la práctica común es usar
@fopen($file);
y luego verifique luego ... pero puede deshacerse del @ haciendo
if (file_exists($file))
{
fopen($file);
}
else
{
die(''File not found'');
}
o similar.
Supongo que la pregunta es: ¿hay alguna parte que @ tenga que usarse para suprimir un error, que NO PUEDE manejarse de ninguna otra manera?
El único lugar donde realmente necesitaba usarlo es la función eval. El problema con eval es que, cuando la cadena no se puede analizar debido a un error de sintaxis, eval no devuelve falso, sino que arroja un error, al igual que tener un error de análisis en el script normal. Para verificar si el script almacenado en la cadena es analizable, puede usar algo como:
$script_ok = @eval(''return true; ''.$script);
AFAIK, esta es la manera más elegante de hacer esto.
La mayoría de las personas no entienden el significado del mensaje de error.
En serio. La mayoría de ellos.
Ellos piensan que los mensajes de error son todos iguales, dice "¡Algo sale mal!"
No se molestan en leerlo.
Si bien es la parte más importante del mensaje de error, no solo el hecho de que se ha planteado, sino su significado. Te puede decir lo que está pasando mal. Los mensajes de error son de ayuda, no para molestarlo con "¿cómo ocultarlo?" problema. Ese es uno de los mayores malentendidos en el mundo de la programación web para novatos.
Por lo tanto, en lugar de un mensaje de error de arcadas, uno debe leer lo que dice. No tiene solo un valor de "archivo no encontrado". Puede haber miles de errores diferentes: permission denied , save mode restriction open_basedir restriction , etc.etc. Cada uno requiere acción apropiada. ¡Pero si lo amordazas nunca sabrás lo que sucedió!
¡El OP está arruinando los informes de errores con el manejo de errores, mientras que la diferencia es muy grande!
El manejo de errores es para el usuario. "algo pasó" es suficiente aquí.
Si bien los informes de errores son para programadores, quienes necesitan saber con desesperación qué pasó.
Por lo tanto, nunca gag mensajes de errores. Ambos lo registran para el programador y lo manejan para el usuario.
Lo uso cuando intento cargar un archivo HTML para procesarlo como un objeto DOMDocument. Si hay algún problema en el HTML ... y qué sitio web no tiene al menos uno ... DOMDocument-> loadHTMLFile () arrojará un error si no lo suprime con @. Esta es la única forma (tal vez hay otras mejores). He tenido éxito al crear raspadores HTML en PHP.
NUNCA me permito usar ''@'' ... period.
Cuando descubro el uso de ''@'' en el código, agrego comentarios para hacerlo más evidente, tanto en el punto de uso como en el docblock alrededor de la función donde se usa. A mí también me ha picado la depuración de "perseguir a un fantasma" debido a este tipo de supresión de errores, y espero que sea más fácil para la siguiente persona al resaltar su uso cuando lo encuentre.
En los casos en que deseo que mi propio código arroje una excepción si una función PHP nativa encuentra un error, y ''@'' parece ser la manera más fácil de hacerlo, prefiero hacer otra cosa que obtenga el mismo resultado pero es (nuevamente) evidente en el código:
$orig = error_reporting(); // capture original error level
error_reporting(0); // suppress all errors
$result = native_func(); // native_func() is expected to return FALSE when it errors
error_reporting($orig); // restore error reporting to its original level
if (false === $result) { throw new Exception(''native_func() failed''); }
Eso es mucho más código que simplemente escribir:
$result = @native_func();
pero prefiero que mi supresión sea MUY OBVIA, por el mal alma que me sigue.
No desea suprimir todo, ya que ralentiza su script.
Y sí, hay una forma tanto en php.ini como dentro de su script para eliminar errores (pero solo haga esto cuando se encuentre en un entorno en vivo y logre registrar sus errores desde php)
<?php
error_reporting(0);
?>
Y puede leer this para la versión php.ini de apagarlo.
Nota: En primer lugar, me doy cuenta de que el 99% de los desarrolladores de PHP usan el operador de supresión de errores (yo solía ser uno de ellos), así que estoy esperando que cualquier desarrollador de PHP que vea esto no esté de acuerdo.
En su opinión, ¿es siempre válido usar el operador @ para suprimir un error / advertencia en PHP mientras que usted puede estar manejando el error?
Respuesta corta:
¡No!
Más tiempo más respuesta correcta:
No sé, ya que no sé todo, pero hasta ahora no he encontrado una situación en la que fuera una buena solución.
Por qué es malo:
En lo que creo que son unos 7 años usando PHP ahora, he visto una agonía sin fin de depuración causada por el operador de supresión de errores y nunca he encontrado una situación en la que sea inevitable.
El problema es que la pieza de código para la que está suprimiendo los errores, actualmente solo puede causar el error que está viendo; sin embargo, cuando cambia el código en el que se basa la línea suprimida, o el entorno en el que se ejecuta, entonces hay muchas posibilidades de que la línea intente generar un error completamente diferente al que estaba tratando de ignorar. Entonces, ¿cómo rastrear un error que no está dando salida? Bienvenido a depurar el infierno!
Me tomó muchos años darme cuenta de cuánto tiempo estaba perdiendo cada dos meses debido a errores reprimidos. Muy a menudo (pero no exclusivamente) esto fue después de instalar un script / aplicación / biblioteca de un tercero que no contenía errores en el entorno de desarrolladores, pero no mía debido a una diferencia de configuración de servidor o php o dependencia faltante que normalmente generaría un error inmediatamente alertando sobre el problema, pero no cuando el desarrollador agrega la magia @.
Las alternativas (dependiendo de la situación y el resultado deseado):
Maneje el error real que conoce, de modo que si una parte del código causa un cierto error, entonces no se ejecuta en esa situación particular. Pero creo que obtienes esta parte y te preocupaba que los usuarios finales vean errores, que es lo que ahora abordaré.
Para los errores comunes, puede configurar un manejador de errores para que salgan de la manera que desee cuando está viendo la página, pero ocultos para los usuarios finales y registrados, para que sepa qué errores están desencadenando los usuarios.
Para los errores fatales, configure display_errors en off (su manejador de errores aún se activa) en su php.ini y habilite el registro de errores. Si tiene un servidor de desarrollo, así como un servidor en vivo (que recomiendo), este paso no es necesario en su servidor de desarrollo, por lo que aún puede depurar estos errores fatales sin tener que recurrir a buscar el archivo de registro de errores. Incluso hay un truco usando la función de apagado para enviar una gran cantidad de errores fatales a su controlador de errores.
En resumen:
Por favor evítalo. Puede haber una buena razón para ello, pero todavía tengo que ver uno, por lo que hasta ese día es mi opinión que el operador de supresión de errores (@) es malo.
Puede leer mi comentario en la página Operadores de control de errores en el manual de PHP si desea más información.
Sí, la supresión tiene sentido.
Por ejemplo, el comando fopen() devuelve FALSE si el archivo no se puede abrir. Está bien, pero también produce un mensaje de advertencia de PHP. A menudo no quieres la advertencia: verificarás por ti mismo FALSE .
De hecho, el manual de PHP sugiere específicamente usar @ en este caso.
Se debe evitar la supresión de errores a menos que sepa que puede manejar todas las condiciones.
Esto puede ser mucho más difícil de lo que parece al principio.
Lo que realmente debe hacer es confiar en el "error_log" de php como su método de informe, ya que no puede confiar en que los usuarios vean las páginas para informar errores. (Y también debe deshabilitar php para que no muestre estos errores)
Entonces, al menos, tendrá un informe completo de todas las cosas que van mal en el sistema.
Si realmente debe manejar los errores, puede crear un manejador de errores personalizado
http://php.net/set-error-handler
Entonces, posiblemente podría enviar excepciones (que se pueden manejar) y hacer todo lo necesario para informar errores extraños a la administración.
Si está utilizando una función de manejo de errores personalizada y quiere suprimir un error (probablemente un error conocido), use este método. El uso de ''@'' no es una buena idea en este contexto, ya que no suprimirá el error si se configura el manejador de errores.
Escribe 3 funciones y llama así.
# supress error for this statement
supress_error_start();
$mail_sent = mail($EmailTo, $Subject, $message,$headers);
supress_error_end(); #Don''t forgot to call this to restore error.
function supress_error_start(){
set_error_handler(''nothing'');
error_reporting(0);
}
function supress_error_end(){
set_error_handler(''my_err_handler'');
error_reporting(''Set this to a value of your choice'');
}
function nothing(){ #Empty function
}
function my_err_handler(''arguments will come here''){
//Your own error handling routines will come here
}
Si no desea una advertencia lanzada al usar funciones como fopen (), puede suprimir el error pero usar excepciones:
try {
if (($fp = @fopen($filename, "r")) == false) {
throw new Exception;
} else {
do_file_stuff();
}
} catch (Exception $e) {
handle_exception();
}
Suprimiría el error y lo manejaría . De lo contrario, puede tener un problema TOCTOU (tiempo de comprobación, tiempo de uso. Por ejemplo, un archivo puede eliminarse después de que file_exists devuelva true, pero antes fopen).
Pero no solo suprimiría los errores para hacerlos desaparecer. Estos serán mejores visibles.
Un lugar donde lo uso está en el código del socket, por ejemplo, si tiene un tiempo de espera establecido recibirá una advertencia si no incluye @, aunque es válido para no obtener un paquete.
$data_len = @socket_recvfrom( $sock, $buffer, 512, 0, $remote_host, $remote_port )
Usar @ es a veces contraproducente. En mi experiencia, siempre debes desactivar los informes de errores en php.ini o llamar
error_reporting(0);
en un sitio de producción. De esta manera, cuando esté en desarrollo, puede comentar la línea y mantener los errores visibles para la depuración.