Discussion :

[Djakisback]

Salut,
j'ai l'habitude de ne jamais utiliser le @ pour l'affichage de variables mais plutôt isset() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php echo isset($_GET['var']) ? $_GET['var']) : '';?>

mais finalement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php echo @$_GET['var'];?>

éclaircit pas mal le code.
Savez-vous si le @ est voué à disparaître dans les prochaines versions de PHP ou s'il peut poser problème ? Est-ce que vous l'utiliser ?

Merci d'avance.

[Mr N.]

Je proscrit l'utilisation du @
On ne désactive jamais les erreurs !

De plus tes deux codes ne sont pas strictement équivalent. Car '' n'est pas === à false Preuve que ce @ est utilisé bien trop abusivement

[Maxoo]

Mr N. >> pour revenir au isset car c'est beaucoup mieux que @

il parait que le isset provoque une erreur en PHP5 ?
vrai ? faux ?

[Mr N.]

Je sais pas, j'utilise pas php5

[zyongh]

Je ne vois pas en quoi utiliser le @ pose un problème? Je vois plutôt un avantage au point de vue sécurité.

Je précise aussi qu'à chaque fois que je l'utilise je redirige les erreurs qui pourraient être générées vers un fichier log de telle sorte que je suis le seul à en prendre connaissance et non les internautes.

Donc, je vote oui pour le @

[viviboss]

Lol
Pour rediriger les erreurs vers un log, je suppose que tu utilise la classe "exception", avec un piti "throw new exception" ?

Certe, c'est bien.... En Objet !!!! (lol, vieille chamaille entre en Zyongh et moi entre l'utilisation du procédural et de l'objet.... )

Bref, le @ je dis non pour le procédurale, mais si effectivement ca peut apporter des améliorations de sécurité comme l'utilise Zyongh, alors chui pour !!!

[Mr N.]

Je précise aussi qu'à chaque fois que je l'utilise je redirige les erreurs qui pourraient être générées vers un fichier log de telle sorte que je suis le seul à en prendre connaissance et non les internautes.

Faux. En tout cas sur ma config.

Je te propose de faire un test.
- Tu observes ton fichier de log ("tail -f /var/log/httpd/error_log" chez moi sur *nix)
- Tu crées un fichier contenant une erreur du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php test_error(); ?>

- Tu appelles ce script dans ton navigateur, et tu observes ton fichier de logs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[client X.X.X.X] PHP Fatal error:  Call to undefined function:  test_error() in www/test_error.php on line 2

- Maintenant tu rajoutes le @ devant test_error() => pas d'erreurs dans le fichier de log !

Le but de @ est d'invalider les erreurs et de retourner false à la place.

Pour ton besoin, tu dois utiliser display_errors=off, pas @

[genova]

Je ne vois pas en quoi utiliser le @ pose un problème? Je vois plutôt un avantage au point de vue sécurité.

Faux ! La preuve dans le premier message :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<?php echo @$_GET['var'];?>

Aucune vérification du contenu.

S'il s'agissait simplement d'éclaircir le code, autant faire une fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
function request($key)
{
   return ((isset($_REQUEST[$key])) ? : NULL);
}
 
echo request('var');

Lorsqu'il y a une erreur, PHP appel son handler d'erreur (voir la fonction trigger_error() et set_error_handler()). Dans cette fonction, en fonction de l'error_reporting (accessible via la fonction error_reporting()), PHP affichera ou non l'erreur.

En passant @ devant une fonction, on met automatiquement l'error_reporting() sur 0, donc la fonction d'erreur de PHP n'affiche pas l'erreur.

On peut le voir facilement avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<?php
function my_handler($errno, $errstr, $file, $line)
{
   echo 'Error reporting = ' . intval(error_reporting()) . '<br />';
}
set_error_handler('my_handler');
 
trigger_error('Erreur', E_USER_NOTICE);
@trigger_error('Erreur', E_USER_NOTICE);
?>

Le @ n'est pas sécurisé, dans le sens ou dissmuler une erreur, ce n'est pas faire disparaitre une erreur, et un jour ou l'autre ça peut poser problème si on ne sait pas ce qu'on fait. Mieux vaut jouer sur l'error_reporting() pour la gestion des erreurs plutot.

Cependant @ est utile dans pas mal de cas (notament là où on veut faire des api portables, ou bien si on veut dissimuler un warning qu'on traite cependant juste après différement).

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (!@ma_fonction_faisant_un_warning())
{
   // Je gère le cas ou ma_fonction_faisant_un_warning() foire
}

[Maxoo]

Je sais pas, j'utilise pas php5

je crois qu'une discussion avait été crée, mais je la retrouve pas.

on parlait de isset et de array_key_exist ... car en PHP5 isset générait une erreur de notice ...

Voila.

[Fladnag]

je pense que zyongh parlait plutot d'une syntaxe comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

@methode() or logError("error on methode() at ".__FILE__);

par exemple.

en fait l'utilisation de @ doit etre reservé a des gens qui SAVENT ce qu'ils font, et n'est pas pour le débutant... mais c'est quand meme bien pratique de pouvoir masquer les erreurs d'une fonction si on a bien conscience que la fonction PEUT generer une erreur et que notre code DOIT gerer ce cas derriere.

Parmis les formes les plus communes que j'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@mysql_query($sql) or erreurSQL($req); // erreurSQL log l'erreur evidemment
@mysql_result(...) or erreurSQL(...);
@list($var1, $var2, $var3) = $tableau; // quand j'ai la flemme de tester si mon tableau a bien 3 elements... je sais, c'est pas beau ;o)

mais sinon je n'utilise jamais @$_GET['variable'] ou autre chose de ce genre... le isset est fait pour ca.