juin
2009
Comme toute application, lorsque vous développez une application GAE, vous êtes inévitablement confronté à un moment ou à un autre à des erreurs :
- pendant le développement
- pendant le déploiement
- pendant l’execution sur GAE
Je pense qu’un problème bien identifié est à moitié résolu.
Voyons donc quels sont les outils mis à votre disposition par GAE pour débusquer ces vilains cafards …
=> Les erreurs pendant la phase de développement.
Sur ce point, c’est assez classique. Vous avez dans Eclipse tout l’arsenal habituel : de la simple console pour afficher vos sorties systèmes au débugger plus évolué.
Notons juste que Google met à votre disposition
- une implémentation locale des services qu’il propose
- de quoi écrire des tests unitaires
Voici un exemple d’erreur serveur dans l’environnement de développement (Serveur Jetty embarqué) :
=> Les erreurs pendant la phase de déploiement.
Sur ce point, la console sera votre meilleure alliée (Comme l’illustre l’exemple de mon précédent billet à propos de la limite du nombre de fichiers statiques).
Notons qu’en dehors de Developpez.com, vous pouvez posé vos questions sur
=> Les erreurs pendant l’execution sur GAE.
J’ai gardé le meilleur pour la fin ! (comprenez : « Ce qui vous intéresse le plus !!! »)
Si vous en arrivez là, c’est que vous n’avez pas rencontré de problèmes particuliers lors des phases précédentes ou que vous les avez résolus.
Vous vous attendez donc à ce que ça roule mais ce n’est pas le cas !
- Au pire, vous ne voyez pas de message d’erreur mais cela ne fonctionne pas.
- Au mieux, vous recevez une erreur générale.
Dans l’environnement d’execution (Serveur Jetty spécial GAE), mon premier exemple d’erreur devient :
Comme vous pouvez vous en rendre compte, le message est légèrement différent : Le détail de l’exception est caché à l’utilisateur !
- Ce qui n’est pas forcément une mauvaise chose car cela évite de montrer des détails d’implémentation.
- Ce qui ne serait pas forcément une bonne chose pour le développeur s’il ne pouvait avoir plus de détails.
La difficulté, c’est que vous n’avez plus la main sur la machine ou s’exécute votre code mais heureusement, vous avez accès à une console de logs dans GAE :
Et d’un détail de la trace en cliquant sur le « + » :
Quelques remarques :
- Quand vous consultez les logs de votre application GAE, pensez à choisir la bonne version dans votre tableau de bord. J’ai mis un temps fou à trouver ma première erreur car malgré toutes les traces que je rajoutais au fur et à mesure de mes déploiements successifs, je ne voyais rien, doutant même de ma façon de procéder jusqu’au moment où je me suis rendu compte que je n’étais pas positionné sur la bonne version.
- Vous disposez de quelques options pour filtrer les logs, la plus importante étant le niveau de trace : de Debug à Critique. L’utilisation de couleurs distinctes pour chaque niveau aide à la consultation. Ces niveaux correspondent à ceux du système de log intégré au JDK car c’est celui qu’utilise GAE.
- Par défaut, les exceptions non interceptées graves (comme une erreur serveur) apparaitront en critique (C rouge) et les autres en erreur (E orange).
De plus, si vous n’utilisez que les sorties standards (System.out et System.err) pour vos messages, les premiers sont loggés avec un niveau Info (I vert) et les seconds avec un niveau Warning (W Jaune). - Pour avoir les messages de débuggage (D bleu) ou d’information vert (I vert) dans la console, n’oubliez pas de modifier le fichier war\WEB-INF\logging.properties en passant par exemple .level=WARNING à .level=FINE.
- Les logs peuvent être téléchargés sur votre poste de développement à partir des outils fournis (batch/tâche Ant de GAE)
- Les logs ne peuvent être effacés pour l’instant et c’est la seule petite critique que je ferai dans ce tour d’horizon de la console de logs.