En production plusieurs cause peuvent entraîner l’arrêt ou le dysfonctionnement d’une application javascript. Avec l’augmentation des développements front end il est maintenant indispensable de savoir les éviter et les gérer pour une analyse ultérieur. Cet article traite de 3 niveaux de gestion à mettre en place.

1. Eviter les erreurs de syntaxe

C’est indéniablement l’erreur qui a la plus grave conséquence, l’arrêt total de l’application. Mais c’est aussi la plus simple à avoir si le code produit n’est pas rigoureusement testé.

Beaucoup d’IDE permettent d’éviter les erreurs grossières de syntaxe, mais nous ne somme jamais à l’abri d’un d’oubli… Ce n’est donc pas du luxe que d’analyser une dernière fois le code avant une mise en production. L’analyseur de code JSHINT permet de dresser un rapport sur l’état de votre code avant une éventuelle mise en production. Il ne s’arrête pas là puisqu’il vous fournira aussi un rapport contenant en autre les variables “undefined”, non utilisées, déclarées plusieurs fois …

2. Capturer les “exception”, les erreurs type ReferenceError ou toutes les erreurs provenant de librairies externes

En production, il peut être intéressant de garder un œil sur les erreurs qui peuvent être levées, qu’elles soit originaires de votre propre développement ou de librairies externes. Les navigateurs proposent l’événement window.onerror  levé à chaque erreurs javascript rencontrées. Il permet ainsi de détecter les exceptions, mais aussi les erreurs de référence ou toutes erreurs des librairies externes.

window.onerror = function(message, url, lineNumber) {
    console.info(message);
    console.info(url);
    console.info(lineNumber);
};

Attention au crossdomaine. Si cet évènement est levé par un script qui ne se trouve pas sur le même domaine/sous domaine alors le message sera “Script error.” et le code “0”. C’est une limitation volontaire des navigateurs pour une raison de sécurité.

Cette technique est donc le dernier filet avant de perdre la trace d’une erreur. Elle peut s’avérer peu précise pour les exceptions levées avec un objet. Limité aux paramètres “message”, “url”, “lineNumber”, les données contenues dans un object ne seront pas transmises par l’évènement. Pour une gestion plus poussées dans exceptions il faudra passer au point 3.

3 – Capturer les exceptions

Aucun autre moyen à ma connaissance existe pour capturer et traiter une exception. Il faudra passer pas un bloc try..catch général à votre application.

Couplé à une requête ajax, les 2 derniers points vous permettront de mettre en place un système de log de toutes les erreurs rencontrées coté client.