isset ($ var) vs. @ $ var

Question

¿Es esta una práctica aceptable o una forma aceptable de usar la supresión de errores de PHP?

if (isset($_REQUEST['id']) && $_REQUEST['id'] == 6) { 
    echo 'hi'; 
} 

if (@$_REQUEST['id'] == 6) { 
    echo 'hi'; 
} 

EDIT:
Yo pensaba lo mismo. El código (y la idea) es de amigo.
Gracias por probarme lo correcto. :)

Answer 1

No es una buena práctica usar la supresión de errores. Ni siquiera es una buena práctica usar $ _REQUEST en absoluto. Solo use isset() o! Empty() o lo que sea, no sea flojo.

Y una cosa más, se trata de una "buena práctica" para cerrar el paréntesis cuando se utiliza isset() :)

Answer 2

siempre uso isset() ya que es más específico. Además, usaría una variable superglobal más específica, así que use $ _POST, $ _GET, $ _SESSION. Ser claro con su código evita dolores de cabeza más adelante :)

Así es como me paso los controles:

if(isset($_POST['id']) && $_POST['id'] == '6') 
{ 
    // do stuff 
} 

Esto es bastante exhaustiva comprobación, ya que comprueba si hay una existencia de un puesto, a continuación, si la variable de mi es parte de la publicación, y finalmente si esos dos pasan, comprueba si mi variable es igual a 6.

Answer 3

No, en realidad no es una práctica aceptable en mi opinión. Además del hecho de que parece descuidado, los controladores de errores personalizados todavía se activan incluso cuando se usa la supresión de errores.

El manual ofrece más razones para evitar su uso por completo:

la actualidad, el "@" para control de errores del operador prefijo deshabilitará incluso informes de errores críticos que terminarán la ejecución del script. Entre otras cosas, esto significa que si usa "@" para suprimir los errores de una determinada función y, o bien no está disponible o ha sido mal escrita, la secuencia de comandos morirá allí mismo sin ninguna indicación de por qué.

Answer 4

Al suprimir los errores utilizando @, solo se suprime la visualización del error, no la creación. Entonces, obtiene un pequeño golpe de rendimiento del error si no marca isset() primero.

Answer 5

Además de no ser una buena práctica, dado que @ puede masticar errores realmente importantes en la pila de llamadas, la penalización de rendimiento es minúscula.

Vamos a verificar esto con un punto de referencia.

<?php 
error_reporting(-1); 

$limit = 10000; 

$start = microtime(true); 
for ($i = 0; $i < 10000; $i++) { 
    echo !isset($_GET['aaa']) ? '' : $_GET['aaa']; 
} 
$total = 1000000 * (microtime(true) - $start)/$limit; 
echo "With isset: $total μs\n"; 

$start = microtime(true); 
for ($i = 0; $i < 10000; $i++) { 
    echo @$_GET['aaa']; 
} 
$total = 1000000 * (microtime(true) - $start)/$limit; 
echo "With @: $total μs\n"; 

En mi ordenador no tan reciente que da salida:

With isset: 0.295 μs 
With @: 0.657 μs 

mu s es una millonésima parte de un segundo. Ambos métodos toman cerca de la mitad de una millonésima de segundo.

Uno podría decir, pero ¿y si hago esto por cientos o miles de veces, habrá alguna diferencia? ¡Si tiene que hacer !isset() un millón de veces, entonces su programa ya pasó aproximadamente 0.3 segundos haciendo esto! Lo que significa que no deberías haber estado haciendo eso en primer lugar.

Sin embargo, @ es una mala práctica para algo más complejo que una simple matriz, por lo tanto, no lo use incluso si usted sabe que la diferencia de rendimiento es insignificante.