Suprimir el error con el operador @ en PHP

Question

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ía esto?

Ejemplos de código son bienvenidos.

Editar: Nota para los replicantes. No estoy en busca de convertir el informe de errores fuera, pero, por ejemplo, la práctica común es utilizar

@fopen($file); 

y después comprobar después ... pero usted puede deshacerse de la @ 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?

Answer 1

que suprimiría el error y manejarlo . 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 devuelve true, pero antes fopen).

Pero no me limitaría a suprimir los errores para que desaparezcan. Estos serán mejores visibles.

Answer 2

Sí 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 el FALSE tú mismo.

De hecho, el PHP manual sugiere específicamente usar @ en este caso.

Answer 3

¿No hay forma de evitar 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.

Answer 4

No desea suprimir todo, ya que ralentiza su secuencia de comandos.

Y sí hay una manera tanto en php.ini y dentro de su script para eliminar errores (pero sólo hacerlo cuando se está en un entorno real y registrar sus errores de php)

<?php 
    error_reporting(0); 
?> 

Y usted puede leer this para la versión php.ini de apagarlo.

Answer 5

Se debe evitar la supresión de errores a menos que conozca 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 fallan en el sistema.

Si realmente tiene que manejar los errores, puede crear un controlador de errores personalizado

http://php.net/set-error-handler

Entonces usted podría enviar excepciones (que pueden ser manejados) y hacer lo necesario para reportar errores extraños a la administración .

Answer 6

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 un ... 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.

Answer 7

Usar @ a veces es contraproducente. En mi experiencia, siempre debe desactivar el informe de errores en php.ini o llamar al

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.

Answer 8

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) 

Answer 9

Si no desea una advertencia lanzada al utilizar funciones como fopen(), puede suprimir el error pero el uso de excepciones:

try { 
    if (($fp = @fopen($filename, "r")) == false) { 
     throw new Exception; 
    } else { 
     do_file_stuff(); 
    } 
} catch (Exception $e) { 
    handle_exception(); 
} 

Answer 10

Nota: En primer lugar, me doy cuenta de que el 99% de los desarrolladores de PHP usan el operador de supresión de errores (solía ser uno de ellos), así que estoy esperando que cualquier desarrollador de PHP lo vea en desacuerdo.

En su opinión, ¿es siempre válido utilizar el operador @ para suprimir un error/advertencia en PHP mientras que usted puede estar manejando el error?

Respuesta corta:
No!

más larga respuesta más correcta:
no sé como yo no lo sé todo, pero hasta ahora no me he encontrado con una situación en la que era una buena solución.

Por qué es malo:
En lo que creo que es de aproximadamente 7 años usando PHP ahora he visto agonía sin fin depuración causado por el operador supresión de errores y nunca he encontrado con una situación en la que era 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 suprimidos. 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 resultado deseado):
controlar el error real que usted está enterado de, por lo que si una pieza de código va a causar 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 habituales, puede configurar un manejador de errores para que salgan de la forma que desee cuando está viendo la página, pero ocultos para los usuarios finales y registrados, para saber qué errores están desencadenando los usuarios.

En los errores fatales, configure display_errors como desactivado (su manejador de errores aún se desencadena) 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 trick using the shutdown function para enviar una gran cantidad de errores fatales a su controlador de errores.

En resumen:
Por favor, evitarlo. 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 my comment on the Error Control Operators page en el manual de PHP si desea más información.

Answer 11

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 nativa de PHP encuentra un error, y '@' parece ser la manera más fácil de hacerlo, prefiero hacer otra cosa que consiga la mismo resultado, pero es (de nuevo) salta a la vista 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 acaba de escribir:

$result = @native_func(); 

pero prefiero hacer mi supresión necesita muy obvio, en aras del pobre alma depuradora que me sigue.

Answer 12

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. Con el fin de comprobar si la secuencia de comandos almacenado en la cadena es analizable se puede usar algo como:

$script_ok = @eval('return true; '.$script); 

yo sepa, esta es la manera más elegante de hacer esto.

Answer 13

Si está utilizando una función personalizada de manejo de errores y quiere suprimir un error (probablemente un error conocido), utilice 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.

Escriba 3 funciones y llame de esta manera.

# 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 
} 

Answer 14

La mayoría de las personas no entiende el significado del mensaje de error.
No es broma. La mayoría de ellos.

Ellos piensan que los mensajes de error son todos iguales, dice "¡Algo va 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. Puede decirle lo que está fallando. 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 mensaje de error de amordazamiento, 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 PO está arruinando error informes con el error manejo, mientras que es muy grande la diferencia!
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 qué pasó con certeza.

Por lo tanto, nunca gag mensajes de error. Ambos lo registran para el programador, y lo manejan para el usuario.