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 @

[titoon]

Perso, je déconseille vivement l'utilisation du @ (sauf très rares exceptions... typiquement dans la fonction qui gère les erreurs)

Je confirme ce que dis Mr N : les erreurs ignorées via @ ne sont pas logués

Djakisback, si tu aimes le @ pour la syntaxe... pourquoi tu ne fais pas une fonction ?

Code :

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

1
2
3
4
5
6
7
8
 
function a($var) {
 if (isset($var))
  echo $var;
}
a($truc); // n'affiche rien (car $truc est null)
$truc = 5;
a($truc); // affiche 5

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

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

[Mr N.]

Même dans ce cas on peut s'en sortir autrement :

Code :

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

1
2
3
4
5
6
 
if (on_est_dans_un_cas_ou_ma_fonction_ne_fera_pas_de_warning()) {
   ma_fonction();
} else {
   // Je gère le cas ou ma_fonction foire
}

C'est le cas classique du fopen. Plutot que d'utiliser @fopen('bad/file', 'r'), autant tester au préalable que le fichier existe bien avec file_exists...

[Fladnag]

pour le cas du fopen...

imagine que tu as du fopen($fichier, 'a'), si tu veux faire tout les tests necessaires il te faut au moins :

* file_exists()
* is_writeable()
* is_writeable() sur le dossier parent

et encore, comme ce n'est pas une opération atomique, tu ne peut pas gerer le cas de l'acces concurrentiel par un autre thread au meme fichier ou dossier (genre suppression du repertoire entre le test et le fopen) sans alourdir encore avec des flock de partout. sans oublier clear_stat_cache pour bien finir de plomber les perfs ;o)

Bref, je prefere 1000 fois un beau :

Code :

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

1
2
3
4
$f=@file($fichier, 'a');
if ($f === FALSE) {
   logError("Impossible d'acceder en écriture au fichier $fichier");
}

[genova]

Sauf qu'en cas d'erreur tu ne sauras pas d'où ça vient.

Alors qu'avec :

Code :

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

1
2
3
4
5
6
7
8
9
$file = '/path/file.txt';
if (!file_exists($file))
{
   trigger_error('Fichier inexistant ...');
}
else if (!is_writable($file))
{
   trigger_error('Fichier non accessible en écriture');
}

C'est plus propre, plus sécurisé, moins de soucis d'erreur. bref c'est ce qui fait générablement la différence avec un code fait à l'arache. Et non ça ne te plombera pas les performances.

[Fladnag]

rien ne t'empeche de faire les tests a posteriori si tu veux vraiment du code propre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
$f=@file($fichier, 'a');
if ($f === FALSE) {
   clearstatcache();
   if (!file_exists($fichier)) {
      logError("$fichier n'existe pas");
   } elseif (!is_writeable($fichier)) {
      logError("$fichier n'est pas accessible en écriture");
   } else {
      logError("Erreur inconnue lors de l'acces a $fichier");
   }
}

Pour ce qui est des perfs, c'est clearstatcache qui est un peu gourmand... mais si tu travaille sur plein de fichiers que tu *peux* avoir créé dans ton code précédemment, tu doit l'utiliser pour obtenir un résultat correct de la fonction file_exists...

Ce dernier code est donc :
* optimisé
* sécurisé
* propre
* ET utilise intelligement @
;o)

[Mr N.]

* propre
* ET utilise intelligement @

+1

[zyongh]

Pour toutes les astuces, on peut toujours trouver du code de m... pour démontrer le contraire!!!

J'utilise le @ de telle façon que primo: le warning est invisible à l'écran pour l'utilisateur et secundo: j'envoie un message d'erreur perso et codé dans un fichier de log.

Genova:

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

Je pense que quelqu'un qui code ce genre de ligne connait PHP depuis environ 5 minutes seulement.

C'est évident que ce genre d'utilisation est totalement inutile/

[guitou12]

Pour ma part j'utilise @ aussi quand je veux personnaliser le message d'erreur pour l'utilisateur. Principalement dans la gestion des fichiers

[Mr N.]

Pour toutes les astuces, on peut toujours trouver du code de m... pour démontrer le contraire!!!

Code de m... ??? C'est pas la peine de baser ton argumentation sur des insultes.
Si tu peux trouver du code (tout court ) pour démontrer le contraire, nous sommes tous preneurs, tant que ça peut faire avancer le débat... J'ai mon avis et mes petites habitudes, et je serais plus qu'heureux de les changer si on me montre qu'il y a plus sécurisé, plus lisible ou plus efficace

J'utilise le @ de telle façon que primo: le warning est invisible à l'écran pour l'utilisateur et secundo: j'envoie un message d'erreur perso et codé dans un fichier de log.

C'est exactement le role de display_errors... Donc en gros tu fais du boulot que tu aurais pu deleguer à php...

[Djakisback]

Salut et merci pour ces retours
A vrai dire ce qui m'intéresse surtout c'est l'utilisation du @ dans le cas d'un affichage d'une variable seulement si elle existe :

Par contre si en faisant ca :

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

le warning n'apparaît pas mais qu'il est quand même écrit dans le log, c'est clair que c'est nul.

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

Je pense que quelqu'un qui code ce genre de ligne connait PHP depuis environ 5 minutes seulement.

Lol, la preuve que nan je fais du PHP depuis 4/5 ans et je me pose la question à ce sujet

Euh ok, j'avais pas tilté, en effet le <?php echo @$_GET['var'];?> est un très mauvais exemple, aucune vérif de contenu.