Oui a bannir tous les @

Et oui comme dit AB -> il y a l'aspect sécurité aussi.

Mais aussi:
Si tu logs toutes les erreurs dans un fichier log, et bien l'erreur SQL sera de toute façon inscrite dedans.
Ne pas oublier non plus que si tu ne logs pas les erreurs, tu ne verras que les erreurs produites par toi-même.
Maintenant afficher l'erreur aussi à tous les utilisateurs, je ne pense pas que cela les intéresse

Par contre, moi ce que je fais, j'utilise un code Erreur.
Exemple:

// Q = Query et 11 le query en question
or die('Erreur Q11');

De cette façon, si tu t'organises bien -> tu sais tout de suite à quoi correspond l'erreur Q 11
(Ensuite le fichier log, te donne plus de détails si besoin)

Ou au pire un utilisateur, peut te dire:

"hey j'ai eu une erreur Q11"

(Plus simple a retenir aussi, tu avoueras.)

Moi c'est ce que je fais

Oui il y a l'aspect sécurité aussi.
Mais aussi:
Si tu logs toutes les erreurs dans un fichier log, et bien l'erreur SQL sera de toute façon inscrite dedans.
Maintenant afficher l'erreur à tous les utilisateurs, je ne pense pas que cela les intéresse

Le die ou exit permettra d'afficher une erreur personnalisée de type "Serveur en dérangement" ou "trop de connexions simultanées etc... veuillez réessayer plus tard"
Evidemment il ne faut pas mettre or die(mysql_error()) mais bien or die('trop de connexions simultanées. Veuillez réessayer plus tard') par exemple, en phase d'exploitation. D'ailleurs il ne faut jamais laisser or die(mysql_error()) en phase d'exploitation, on est bien d'accord.

Oups je n'avais pas vue ton Post AB avant mes edits.

Oui on est tout à fait d'accord

[EDIT]
Par contre où je ne suis pas d'accord, c'est que je pense qu'il faut enlever tous les @ même dans ce cas précis.
Il ne faut pas l'afficher mais l'a logguer, c'est tout.
Mais je pense que l'on est d'accord la dessus aussi.

Logguer toutes les erreurs c'est primordial et les cacher c'est un non sens

Vous m'arrangez pas là. Ya un peu de d'accord et un peu de contradiction

Moi je pense que je vais prendre des 2 !

ici je ferais comme ça en production :

$id_con=@mysql_connect(MYHOST,MYUSER,PASSWORD);// OR die(mysql_error());
//sélection de la BDD
$id_base=@mysql_selectdb($bdd);// OR die(mysql_error());

En teste, Je désactive au besoin les @ et je réactive le reste.

Et pour le reste :

 $result=@mysql_query($requete,$id_con);
    mysql_close($id_con);
    if(!$result)
    {
        die('Une erreur s\'est produite');//echo mysql_error();
    }

Sauf qu'ici je pense que mon die ne s'affichera pas car j'ai un @ sur le $result de ma requête, donc à enlever ?

Bien , tu fais ce que tu veux.

C'est tout simplement logique, suffit d'y réfléchir un peu par toi-même et ne pas prendre nos propos pour argent comptant.

Si tu caches les erreurs avec un @, eh bien tu ne les verras jamais, tu ne les logueras pas non plus.
Tu ne pourras donc jamais t'apercevoir d'un problème quelconque...
Pour ne pas afficher les erreurs aux utilisateurs, il y a un paramétrage dans le php.ini justement fait pour cela.

Si tu n'utilises pas de or die(), eh bien si une erreur -> le script va continuer malgré l'erreur SQL, et donc en produire d'autres...
Le site ne va donc pas aimer du tout.

Si tu ne logues pas les erreurs, eh bien tu ne verras que tes propres erreurs.

je ne sais pas pour toi, mais pour moi cela me parait super logique

Sauf qu'ici je pense que mon die ne s'affichera pas car j'ai un @ sur le $result de ma requête, donc à enlever ?

Le @ va ne pas afficher l'erreur, c'est tout, il n'a aucune autre action, donc le die() fonctionnera.
Mais si ce sont des utilisateurs qui tombent sur ton die(), eh bien tu n'auras aucun moyen de savoir qu'il y a eu un soucis et donc une erreur.
Et surtout laquelle exactement...

Donc typiquement en phase de test

$connection = mysql_connect($hostname, $username, $password) or die(mysql_error());
//...
$requete = "SELECT nom ...";
$ressource = mysql_query($requete) or die(mysql_error());

En phase d'exploitation

$connection = @mysql_connect($hostname, $username, $password) or die('Erreur de connexion à la bdd');
//...
$requete = "SELECT nom ...";
$ressource = mysql_query($requete);

// Et on vérifie le résultat de toutes façons à la suite (ex : pour plusieurs lignes)
while($result = mysql_fetch_assoc($ressource)) // (comme pour les tableaux) tant qu'une ressource existe, mysql_fetch_assoc ne retourne pas false
{
echo $result['nom'].'<br />';
}

Il faut connaître cette syntaxe avec mysql_query car c'est la solution historique (qui fonctionne encore) mais puisque tu es en phase d'apprentissage ce n'est pas la peine de trop t'attarder, et regarde assez vite du côté de mysqli (peu différent) ou de pdo

As tu une explication logique pour nous, sur le fait de cacher l'erreur avec un @, si tu as désactivé l'affichage dans le php.ini et activé l'enregistrement des erreurs dans un fichier log?

Si tu en as une, autant que moi que l'auteur du Topic, sera intéressé de comprendre.

Parce que c'est une syntaxe qui passe partout.

Par expérience sur de nombreux mutualisés un échec de la connexion au serveur de bdd renverra un message d'erreur et l'on a pas accès au php.ini (ou très peu)

Voilà c'est aussi simple que cela : portabilité.

Ok vue comme ça, je comprends mieux, merci

Ben de toute façon, déjà que je gère très mal les erreurs pour l'instant, j'essaie de trouver le bon compromis et il viendra que par mon expérience et ma pratique de faire pour le mieux.

Ensuite sur le

ce n'est pas la peine de trop t'attarder, et regarde assez vite du côté de mysqli (peu différent) ou de pdo

Mysqli est une extension PHP qui ressemble à Mysql, mais sous un angle sécuritaire différent d'après ce que j'ai lu, même si je n'ai pas tout saisie.

<?php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");

/* Vérification de la connexion */
if (mysqli_connect_errno()) {
    printf("Erreur de connexion : %s\n", mysqli_connect_error());
    exit();
}
$mysqli->query("CREATE TABLE Language SELECT * from CountryLanguage");

La syntaxe est différente et me fait penser à quelque chose que je n'arrive pas trop à digérer pour l'instant...

En fait Mysqli, utilise 2 syntaxes différentes, une syntaxe Objet (Comme PDO) et une syntaxe procédurale (Comme Mysql).

Si tu regardes bien, chaque fonction Mysqli décrite sur php.net, possède des exemples avec les deux syntaxes.
Se sont juste 2 syntaxe différentes, l'action est la même.
La majorité du temps les fonctions Mysqli sont les mêmes que Mysql mais avec un i en plus.

Exemple ici:
http://php.net/manual/fr/mysqli-result.fetch-assoc.php

Donc autant utiliser le style procédural quand on est pas habitué à la programmation Objet.
Cela permet aussi de migrer vers Mysqli plus simplement

Oui, je suis allergique encore à la POO.

Mais, je me pose une question : Dans les livres récents que j'ai, le cours est basé sur Mysql sans le i.
Pourquoi les auteurs ne passent pas directement au Mysqli si ce 1er n'est plus conseillé pour X raison !

Peut être parce que l'extension n'est pas forcément activée ? Ou alors y a t-il d'autres raison ?

C'est pénible de devoir se remettre en question tout le temps Mais c'est dans le cours du temps...et pour le bien de tous surement

Bien comme tu dis il peut y avoir pleins de raisons.
L'année d'édition du livre, la documentation sur le net, les scripts et les exemples sur le net utilisant Mysql...

Mais bon, Mysql fonctionne toujours très bien

Je lisais ça :

pour l'utiliser Mysqli, il faudra quand même désactiver Mysql.

Je suppose que c'est une extension à désactivée ?

tout va dépendre de ton hébergeur.
ovh par exemple ne propose pas MySqli, donc...

J'ai un hébergement chez OVH !
Donc l'intérêt ?!

En passant, tu peux modifier le php.ini sur OVH, que ce soit avec le .htaccess et surement aussi avec un fichier php.ini personnalisé ajouté dans chaque dossiers contenant un fichier Php.
Tu devrais demander au support, et il y a aussi un forum OVH très bien fait et très utile.
Cela me parait fort utile de se renseigner la dessus

Sinon pour en revenir à Mysqli:
Mon avis personnel, serait de te dire:
Si tu as commencé a apprendre MYSQL, alors ne te complique pas la vie avec Mysqli.
Et le jour où tu veux passer à un cran au dessus, alors passe directement à PDO