salut,
je crois qu'il y a un truc a ajouté pour désactiver les messages d'erreur mysql non ? genre si le passe de la base et pas bon, il nous met un truc du genre

$idconnec = @mysql_connect(...)
 
if ( !$idconnec )
{ ....

Traiter l'erreur vaut toujours mieux que la masquer remarque

Rajoute @ devant n'importe quelle fonction, pour ne pas afficher l'éventuelle erreur.

+1 naceroth
 
ouais et puis après on voit tout le monde débarquer sur les forums parce qu'ils ont une erreur et qu'ils savent pas d'où ça vient ce qui est normal vu qu'ils mettent un @ à chaque ligne ou presque...
les erreurs il faut les traiter ! pas les masquer !

Ca ne répond pas à sa question.

On peut masquer ET traiter l'erreur comme je l'ai mis dans ma réponse. Cela réponds a sa question tout en restant rigoureux.

oui, ya pas d'erreur normalement vous inquietez po, c'est juste que c'est pas cool pour la personne qui voit ca.

 
Ben si. traiter l'erreur revient à la masquer. pas la peine de trainer un @ devant chaque fonction quand un or die() la suit (et c'est le traitement d'erreur le plus basique)  
 
La solution @ puis if pour traiter, j'en parle même pas, je deviendrais désagréable

 
J'attends de pied ferme une argumentation reflechie ...

 
Non.

Mais LOL quoi , on voit que vous ne vous êtes pas taper des Junit ... (JAVA)
 
C'est kler qu'il vaut mieux faire un die, c'est toujours mieux qu'un if, mais au final ça revient au même ..

 
C'est tellement difficile à concevoir que l'on doit traiter une erreur quand elle se produit et non pas après qu'elle se soit produite ?  
 
C'est pas de l'argumentation ? je sais, et je vais pas chercher à convaincre quelqu'un que différer le traitement d'une erreur est un non sens.

 
Masquer l'affichage du message d'erreur normal, pas l'envoyer dans le trou noir le plus proche...

 
Tu chipottes là ... Ca change quoi qu'on traite l'erreur sur la meme ligne ou sur celle d'apres  
 
D'autant plus qu'un or die() c'est limité pour traiter l'erreur parce que a part faire un affichage tu peu rien faire.

 
  C'est pas ça qu'il voulait dire   C'est pas une histoire de ligne, c'est une histoire de processus ...
Il te dira ça mieux que moi je pense

bah meme niveau processus, je-ne-vois-pas-ce-que-ca-change

 
Là c'est toi qui chipotte, tu peux parfaitement mettre autre chose que die derrière le or. Un mail() voir même un prout() perso qui traite les erreurs.
 
Quand à pourquoi sur la même ligne plutôt que sur la suivante (et hormis l'utilisation d'une variable dont on peut parfois se passer), elle tient en quelques mots : l'imbécile qui repassera sur ton code après toi. Tu ne peux jamais être sûr de ce qu'il y aura sur la ligne suivante.
 
Je t'assure que tu auras l'air malin avec un code comme

 
avec une erreur dans la première requête et un idiot qui a intercalé quelque chose entre l'erreur et son traitement (ou plutôt son absence de traitement ici)

Ah ben là evidemment, si l'idiot    fais n'imp derriere moi bah spamafote

 
Bah dans un cas l'erreur ce produit, tu continue ton code et tu regarde si la fonction d'avant n'a pas produit d'erreur.
 
Dans le bon cas et l'erreur se produit et génère une excepetion traité ...
 
Valà. Et parfois, mais ça je ne sais pas pourquoi quand une erreure se produit mais qu'elle n'est pas traité correctement, le code après ton if est quand meme executé. Enfin j'ai eu ça qques fois moi, mais je crois que c t surtout une erreure de code.
 
Mais ce que j'ai dit plus haut reste valable LOL

ouais bah si t'oublies le exit()

 
Tient encore un arguement contre ta méthode ça
 
LOL

 
 
Bah si tu pars du principe que tu fais pleins de conneries, tu peu arreter tout de suite hein.

 
Non bien sûr. Mais un gestionnaire d'erreur correct doit quand même limiter ce genre de risque
 
Vive l'atomicité erreur/traitement, je vous le dis