[Configuration] Précisions sur le @

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

Code:

---

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

---

mais finalement :

Code:

---

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

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 :?

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

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

Je sais pas, j'utilise pas php5 :D

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 @;)

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 !!!:D

Citation:

---

Envoyé par zyongh

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:

---

<?php test_error(); ?>

---

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

Code:

---

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

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:

---

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

---

Citation:

---

Envoyé par Mr N.

Je sais pas, j'utilise pas php5 :D

---

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.

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

Code:

---

@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:

---

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.

Citation:

---

Envoyé par 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é.

---

Faux ! La preuve dans le premier message :

Code:

---

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

---

Aucune vérification du contenu.

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

Code:

---

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:

---

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:

---

1 2 3 4

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

---

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

Code:

---

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... :)

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:

---

1 2 3 4

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

---

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

Alors qu'avec :

Code:

---

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.

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

Code:

---

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)

Citation:

---

Envoyé par Fladnag

* propre
* ET utilise intelligement @

---

+1 :ccool:

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

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:

Citation:

---

<?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/

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

Citation:

---

Envoyé par zyongh

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

---

Code de m... ??? C'est pas la peine de baser ton argumentation sur des insultes. :?
Si tu peux trouver du code (tout court :evil: ) 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

Citation:

---

Envoyé par zyongh

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... :roll:

Salut et merci pour ces retours :D
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.

Citation:

---

<?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 :D

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

Citation:

---

Envoyé par Mr N.

Code de m... ??? C'est pas la peine de baser ton argumentation sur des insultes. :?

---

Je suis vraiment désolé que ce soit interprété comme une insulte.:cry:
Ce que je voulais dire c'est que l'on peut toujours critiquer une façon de faire car en informatique il y a toujours plusieurs bonnes solutions.

Citation:

---

Envoyé par Mr N.

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

---

PHP comporte près de 3000 fonctions et je ne les connaîs pas toute!! Et toi??:mouarf:

Bon je te remercie de me l'avoir signalé, je l'utiliserai la prochaine fois que j'en aurai l'occasion.;)

Citation:

---

Envoyé par zyongh

PHP comporte près de 3000 fonctions et je ne les connaîs pas toute!! Et toi??:mouarf:

---

Je peux utiliser un Joker ? :D

Citation:

---

Envoyé par Mr N.

Je peux utiliser un Joker ?

---

Non !!

Citation:

---

Envoyé par zyongh

PHP comporte près de 3000 fonctions et je ne les connaîs pas toute!! Et toi??:mouarf:

---

exactement : 4902 fonctions => http://fr.php.net/quickref.php

(oui, oui je suis au boulot):aie: :aie:

Salut

La morale est donc de :

• Conserver les erreurs dans le fichier de log : configuration de php.ini ;
• Cacher les erreurs à l'utilisateur (ou les personnaliser) : @ ou bien directive de php.ini (j'ai une préférence pour la 2nde méthode) ;
• Ne jamais faire echo $_GET['var'] car ce n'est pas sécurisé : utiliser htmlentities() par exemple.

Citation:

---

Envoyé par Maxoo

exactement : 4902 fonctions => http://fr.php.net/quickref.php

---

Un poil plus si on compte aussi les methodes des divers objets de certaines API internes qui ne sont pas référencées dans la liste

http://fr.php.net/manual/fr/language...reflection.php par exemple.

Citation:

---

Envoyé par Yogui

Salut

La morale est donc de :

---

C'est tout de suite moins marrant ...:mouarf: