Raccourcis : Contenu - rubriques - sous rubriques
EN FR

Les classes du framework peuvent générer des erreurs de deux façons différentes par :

  • un trigger_error (erreur PHP)
  • une exception

Une erreur PHP est générée dans le cas d'une erreur technique due à un défaut dans la programmation. C'est alors au développeur de corriger l'erreur.

Une exception est générée dans le cas d'une erreur qui peut survenir de façon imprévisible durant l'exécution d'une action. Par exemple une erreur suite à l'impossibilité de se connecter sur une base de données ou alors une erreur "fonctionnelle", "métier".

Paramétrage des gestionnaires d'erreurs

Quelle que soit l'origine de l'erreur, celle-ci passe par un gestionnaire d'erreur (sauf les exceptions interceptées par un try/catch). Il y a un gestionnaire d'erreur attribué aux erreurs PHP et un autre attribué aux exceptions, mais ils font au final la même chose.

Ces gestionnaires utilisent jLog pour stocker ou envoyer les messages. Par défault, toutes les erreurs et warnings sont stockés dans un fichier var/log/errors.log.

Vous pouvez changer ce comportement en configurant jLog. Vous pouvez ainsi logger les notices et autres messages PHP. Vous pouvez envoyer les erreurs dans un syslog, par mail etc.

Le format des messages

Les messages d'erreurs stockés dans des fichiers, syslog, mail ou autre, contiennent le message d'erreur lui même, mais aussi les traces de la pile d'appel, et d'autres informations utiles. Vous pouvez indiquer ce que doit contenir le message exactement et de quel manière.

L'option messageLogFormat dans la section [error_handling] de la configuration indique le formatage du message d'erreur. Le formatage supporte des mots clés spéciaux : %date%, %ip%, %typeerror%, %code%, %msg%, %url%, %file%, %line%, %params%, %http_error%, \t et \n.

%params% indique d'afficher tous les paramètres de la requête HTTP. Cependant cela peut poser des problèmes de confidentialité, voire de sécurité, car certains paramètres peuvent être indésirables dans les logs, comme les mots de passes.

Pour l'éviter, vous pouvez retirer ce tag %params% de messageLogFormat.

Ou alors, vous pouvez indiquer quels paramètres il ne faut pas afficher, soit d'une manière général, dans la configuration, soit d'une manière particulière dans les contrôleurs.

Pour l'indiquer dans la configuration, indiquer la liste des noms des paramètres à obfusquer dans VsensitiveParameters@@ de la section error_handling. Par défaut :


[error_handling]
sensitiveParameters = "password,passwd,pwd"

Dans un contrôleur, vous indiquerez la liste dans une propriété $sensitiveParameters :


class passwordCtrl extends jController {

    public $sensitiveParameters = array('pwd', 'pwd_confirm');

    //...
}

Quand vous utilisez jForms, ce dernier informe automatiquement les paramètres correspondant aux champs <secret>.

La page d'erreur

Les détails des messages d'erreurs ne sont pas affichés dans le navigateur (sauf dans la debugbar si vous l'activez). Quand une erreur survient, Jelix affiche une page d'erreur générique avec le code HTTP 500.

Par défaut, il affiche la page lib/jelix/core/response/error.en_US.php. Vous pouvez fournir votre propre page d'erreur en copiant ce fichier dans app/responses/, et en le modifiant en adaptant le design à votre goût.

Notez que error.en_US.php est un simple script PHP. Vous pouvez donc écrire n'importe quel instruction PHP, "à l'ancienne". Cependant, ne faites pas appel aux objets Jelix, ils peuvent ne pas être présent, ou mal initialisé etc. Et ne cherchez pas à afficher le véritable message d'erreur, pour des raisons évidentes de sécurité et de convivialité. En fait, cette page doit être quasi statique. Gardez simplement les instructions echo déjà présente.

Les variables $HEADTOOP, $HEADBOTTOM et $BODYTOP ne sont pour le moment pas utilisées. $BODYBOTTOM contient un message d'erreur "tronqué" : il ne contient pas les détails. Une variable $BASEPATH est disponible, contenant le chemin de base de l'application pour les feuilles de styles etc. Notez que cette variable peut être vide en fonction de la nature de l'erreur (une erreur qui survient avant ou pendant la lecture de la configuration).

La page d'erreur peut ne pas être utilisée dans certains cas :

  • quand une erreur fatale PHP survient
  • quand une erreur survient pendant l'initialisation du framework
  • quand le navigateur n'attend pas du HTML

Dans ce dernier cas, Jelix retourne un simple message texte, qui est configuré dans l'option errorMessage dans la section [error_handling] de la configuration.

Codes erreur

Chaque message d'erreur est traduit dans les fichiers properties et chaque erreur devrait posséder un numéro. Ce numéro est indiqué dans les fichiers properties des messages localisés, de cette façon :


 cle.chaine = (code_erreur)message d'erreur

Le message d'erreur au final ne contiendra pas le code erreur. Et ce dernier sera extrait.

Voici les plages de code erreurs

0-99 erreurs générales
100-199 erreurs du core
200-299 erreurs de locale
300-399 erreurs de templates
400-499 erreurs de bases de données
500-599 erreurs de daos
600-699 erreurs d'authentification
700-799 erreurs de droits
800-899 erreurs jforms
> 5000 erreurs utilisateurs

Si vous générez des erreurs pour vos propres besoins, leurs codes doivent être supérieur à 5000.