J'exposais précédemment ma tactique de traque et d'élimination des erreurs 404 au moyen d'alertes e-mail. Il y a d'autres usages fort utiles pour les alertes par e-mail. Je parlerai aujourd'hui de la traque et de l'élimination des erreurs MySQL.

L'idée est simple : à chaque fois qu'une erreur MySQL se produit, l'administrateur du site est prévenu par un e-mail de la nature de l'erreur et de la requête MySQL qui l'a générée. Mais attendez une minute !, me direz-vous : le développeur est censé déboguer ses requêtes avant la mise en production, et les erreurs de requête ne sont pas censées se produire ! A quoi je répondrai deux choses :

• Citez-moi une seule application qui soit garantie 100% sans bugs : même en vérifiant le type des variables, en construisant les requêtes pièce par pièce, on ne peut pas faire face à toutes les sources d'erreurs. Si l'on se contente de tester l'application en interne, on peut passer à côté d'une erreur récurrente et tout à fait handicapante.
• Il vaut mieux savoir ce que les utilisateurs font avec les formulaires et les variables : saisie erronée, injection de code SQL... Avant de mettre en place un arsenal de fonctions de validation, autant identifier précisément les cas d'abus les plus fréquents.

Une fonction mysql_query personnalisée

Au nombre des fonctions personnalisées que j'utilise quotidiennement, on trouve une fonction mysql_requete, qui n'est autre que la bonne vieille mysql_query personnalisée et enrichie selon mes besoins. C'est au coeur de cette fonction que prennent place les outils de débogage. Voici sa syntaxe :

<?php 

function mysql_requete($requete, $msg_erreur = "Erreur indéfinie")
{
    $resultat = mysql_query($requete);
    if (mysql_error())
    {
        $message_destinataire = "admin@monsite.com";
        $message_titre = "Erreur MySQL sur le script " . $_SERVER['REQUEST_URI'] ;
        $message_corps = "Une erreur MySQL s'est produite sur le script " . $_SERVER['REQUEST_URI'] . "\r\n" .
            "Nature de l'erreur :\r\n" . 
            mysql_error() . "\r\n" .
            "----------------------------------------------\r\n" . 
            "Requête SQL : \r\n" .
            $requete . "\r\n" .
            "----------------------------------------------\r\n" . 
            "Variables d'environnement SERVER : \r\n" .
            print_r($_SERVER, true) . "\r\n" . 
            "----------------------------------------------\r\n" . 
            "Variables d'environnement REQUEST : \r\n" .
            print_r($_REQUEST, true) . "\r\n"
            "----------------------------------------------\r\n" . 
            "Variables d'environnement COOKIE : \r\n" .
            print_r($_COOKIE, true) . "\r\n"
            "----------------------------------------------\r\n" . 
            "Variables d'environnement SESSION : \r\n" .
            print_r($_SESSION, true) . "\r\n";
;

        mail($message_destinataire, $message_titre, $message_corps);
    }
    return $resultat;
}


?>

Eclaircissements

Il n'y a rien de bien compliqué dans cette fonction. Pour l'utiliser, il suffit de remplacer tous les appels à mysql_query() par des appels à mysql_requete() et la gestion des erreurs devient systématique. J'attire toutefois votre attention sur un point en particulier : l'appel de fonction print_r() au sein de la variable $message_corps. La plupart du temps, print_r envoie le résultat vers la sortie (l'affichage) et celui-ci ne peut être récupéré dans une variable. Il suffit pour cela de passer son second paramètre à true. En récupérant le contenu intégral des variables d'environnement, on saura tout ce qu'il faut savoir sur la page demandée, l'état dynamique du serveur et les variables actives du visiteur. Une manière de comprendre le contexte dans lequel s'est produit l'erreur et de faciliter son débogage.