¿Cuándo el @ se vuelve útil?

Question

Como usted sabe, los caracteres @ antes de una estructura de php suprimen cualquier eventual advertencia, error o aviso que se produzca.

Personalmente, no me gusta esta técnica, porque prefiero manejar esos errores, y en la vida real, el error no debe suceder o tiene que ser administrado.

Por cierto, encuentro que esta técnica se aplica en muchos scripts (complementos cms, clases de código abierto).

Entonces, ¿podría @ ser realmente útil (en este caso, se apreciaría un ejemplo), o es solo para desarrolladores perezosos?

Answer 1

Solo piense en, por ejemplo, una llamada fallida mysql_connect. Es posible que desee suprimir el mensaje de error que, de lo contrario, se muestra al usuario (que también muestra algunos detalles que generalmente no desea que nadie más vea) en este caso.

Aunque la advertencia de PHP fue suprimida a través del @ -sign, puede realizar ciertas acciones como mostrar un mensaje de error amistoso al usuario posteriormente.

Sin embargo "mal uso" @ para cosas como en el ejemplo siguiente no es definitivamente una buena idea:

@$undefinedVariable .= 'some text'; 

Hay muchos más ejemplos de mal uso de la señal de supresión de errores por ahí que la anterior , solo debe usarlo cuando no haya otra forma mejor de lograr lo que desea.

Answer 2

Realmente no me gusta @, pero a veces en algunas configuraciones es inevitable.

Personalmente prefiero configurar PHP en la configuración para simplemente registrar errores y silenciosamente fallar en las configuraciones de producción en lugar de usar la muleta @ para suprimir los mensajes.

Buen uso: advertencias. A veces las funciones arrojan advertencias y simplemente no hay nada que puedas hacer sin rediseñar, pero aún funciona correctamente. @ lo suprimirá.

Answer 3

La respuesta a su pregunta es simple y directa: no, @ es inútil, y de hecho nocivo, y no debe utilizarse. Nunca.

La única excepción en la que puedo pensar son las secuencias de comandos "ejecutar una vez", cuando realmente no te importa la calidad y corrección del código.

En los scripts de producción, sugeriría el uso set_error_handler que convierte los errores en excepciones, y try con vacío catch bloque en raros casos en que un error debe ser ignorada:

try { 
    unlink('tempfile'); 
} catch(Exception $e) { 
    // i don't care 
} 

Answer 4

Hay un caso de uso: Si desea probar scream, una extensión PECL que desactiva el operador @. :)

Answer 5

Estoy un poco tarde, pero usar @ en PHP normalmente no es una buena idea. Lo usaría solo para el código de prueba y seguramente no para la producción.

Una forma mucho mejor de manejar errores está utilizando la función set_error_handler (http://ch.php.net/set_error_handler). Si algo sale mal, puede registrar el error (y tal vez notificar al administrador) y luego mostrar un mensaje de error personalizado al usuario o puede ignorarlo si se trata de un aviso/advertencia. (Probablemente ya estés haciendo esto).)

Y aquí es donde el @ es útil de nuevo. Si agrega un @ a un comando y causa cualquier tipo de error, se llamará al manejador de errores de todos modos, pero con el parámetro 'errno' establecido en cero. Echa un vistazo a la lista de los diferentes valores de los niveles de error de php (http://ch.php.net/manual/en/errorfunc.constants.php). Ninguno de ellos es igual a cero, por lo que puede identificar los errores que ocurrieron en las funciones con un precedente @. Podría, por ejemplo, usarlo para "marcar" errores sin importancia (cuando no desee abortar la ejecución, pero asegúrese de registrarlo de todos modos, ya que puede ser útil para la depuración) o utilizarlo para algún otro propósito.

Answer 6

La única situación sería muy útil:

si usted no tiene acceso a php/configuración de Apache y los errores se muestran al usuario.

De lo contrario, NUNCA use @... y redirija los errores (en la configuración de php/apache) a algún sistema de registro (archivo, base de datos, etc.).

PD: En alguna documentación oficial de PHP, puede ver que en lugar de verificar si un archivo existe y luego lo borra, simplemente lo @unlink. Pero no me gusta: prefiero obtener el error en mis registros en caso de problema (derechos de acceso, etc.).