Page d'accueil>Lié à la programmation>Code source JAVA
Télécharger

Manuel des erreurs JavaScript

Ce README contient des informations que j'ai apprises au fil des années sur la gestion des erreurs JavaScript, leur signalement au serveur et la navigation parmi de nombreux bugs qui peuvent rendre tout cela très difficile. Les navigateurs se sont améliorés dans ce domaine, mais il reste encore des progrès à faire pour garantir que toutes les applications peuvent gérer sainement et correctement toute erreur qui se produit.

Les cas de test pour le contenu trouvé dans ce guide sont disponibles sur https://mknichel.github.io/javascript-errors/.

Table des matières

  • Introduction

  • Anatomie d'une erreur JavaScript

    • Générer une erreur JavaScript

    • Messages d'erreur

    • Format de trace de pile

  • Détecter les erreurs JavaScript

    • fenêtre.onerror

    • essayer/attraper

    • Points d'entrée protégés

    • Promesses

    • Travailleurs du Web

    • Extensions Chrome

Introduction

La détection, le signalement et la correction des erreurs constituent une partie importante de toute application pour garantir la santé et la stabilité de l'application. Étant donné que le code JavaScript est également exécuté sur le client et dans de nombreux environnements de navigateur différents, rester au courant des erreurs JS de votre application peut également être difficile. Il n'existe aucune spécification Web formelle sur la manière de signaler les erreurs JS, ce qui entraîne des différences dans l'implémentation de chaque navigateur. De plus, il y a eu de nombreux bugs dans la mise en œuvre des erreurs JavaScript par les navigateurs, ce qui a rendu cela encore plus difficile. Cette page parcourt ces aspects des erreurs JS afin que les futurs développeurs puissent mieux gérer les erreurs et que les navigateurs convergent, espérons-le, vers des solutions standardisées.

Anatomie d'une erreur JavaScript

Une erreur JavaScript est composée de deux éléments principaux : le message d'erreur et la trace de la pile . Le message d'erreur est une chaîne qui décrit ce qui ne va pas, et la trace de pile décrit où dans le code l'erreur s'est produite. Les erreurs JS peuvent être produites soit par le navigateur lui-même, soit par le code de l'application.

Générer une erreur JavaScript

Une erreur JS peut être générée par le navigateur lorsqu'un morceau de code ne s'exécute pas correctement, ou elle peut être générée directement par le code.

Par exemple:

 var une = 3; une ();

Dans cet exemple, une variable qui est en réalité un nombre ne peut pas être invoquée en tant que fonction. Le navigateur générera une erreur du type TypeError: a is not a function avec une trace de pile qui pointe vers cette ligne de code.

Un développeur peut également souhaiter générer une erreur dans un morceau de code si une certaine condition préalable n'est pas remplie. Par exemple

 si (!checkPrecondition()) {
  throw new Error("Ne répond pas aux conditions préalables !");}

Dans ce cas, l'erreur sera Error: Doesn't meet precondition! . Cette erreur contiendra également une trace de pile qui pointe vers la ligne appropriée. Les erreurs générées par le navigateur et le code de l'application peuvent être traitées de la même manière.

Les développeurs peuvent générer une erreur de plusieurs manières en JavaScript :

  • throw new Error('Problem description.')

  • throw Error('Problem description.') <-- équivalent au premier

  • throw 'Problem description.' <-- mauvais

  • throw null <-- encore pire

Lancer une chaîne ou une valeur nulle n'est vraiment pas recommandé car le navigateur n'attachera pas de trace de pile à cette erreur, perdant ainsi le contexte de l'endroit où cette erreur s'est produite dans le code. Il est préférable de lancer un véritable objet Error, qui contiendra le message d'erreur ainsi qu'une trace de pile qui pointe vers les bonnes lignes de code où l'erreur s'est produite.

Messages d'erreur

Chaque navigateur possède son propre ensemble de messages qu'il utilise pour les exceptions intégrées, comme l'exemple ci-dessus pour tenter d'appeler une non-fonction. Les navigateurs essaieront d'utiliser les mêmes messages, mais comme il n'y a aucune spécification, cela n'est pas garanti. Par exemple, Chrome et Firefox utilisent {0} is not a function pour l'exemple ci-dessus tandis qu'IE11 signalera Function expected (notamment également sans signaler quelle variable a été tentée d'être appelée).

Cependant, les navigateurs ont également tendance à diverger souvent. Lorsqu'il y a plusieurs instructions par défaut dans une instruction switch , Chrome lancera "More than one default clause in switch statement" tandis que Firefox signalera "more than one switch default" . À mesure que de nouvelles fonctionnalités sont ajoutées au Web, ces messages d'erreur doivent être mis à jour. Ces différences peuvent entrer en jeu plus tard lorsque vous essayez de gérer les erreurs signalées par du code obscurci.

Vous pouvez trouver les modèles que les navigateurs utilisent pour les messages d'erreur à l'adresse :

  • Firefox - http://mxr.mozilla.org/mozilla1.9.1/source/js/src/js.msg

  • Chrome - https://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/messages.js

  • Internet Explorer - https://github.com/Microsoft/ChakraCore/blob/4e4d4f00f11b2ded23d1885e85fc26fcc96555da/lib/Parser/rterrors.h

Les navigateurs produiront différents messages d'erreur pour certaines exceptions.

Format de trace de pile

La trace de pile est une description de l'endroit où l'erreur s'est produite dans le code. Il est composé d'une série de frames, où chaque frame décrit une ligne particulière du code. L'image la plus haute est l'emplacement où l'erreur a été générée, tandis que les images suivantes sont la pile d'appels de fonction - ou comment le code a été exécuté pour arriver à ce point où l'erreur a été générée. Étant donné que JavaScript est généralement concaténé et réduit, il est également important d'avoir des numéros de colonnes afin que l'instruction exacte puisse être localisée lorsqu'une ligne donnée contient une multitude d'instructions.

Une trace de pile de base dans Chrome ressemble à : 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Chaque cadre de pile se compose d'un nom de fonction (le cas échéant et si le code n'a pas été exécuté dans la portée globale), du script dont il provient et du numéro de ligne et de colonne du code.

Malheureusement, il n'existe pas de norme pour le format de trace de pile, cela diffère donc selon le navigateur.

La trace de pile de Microsoft Edge et IE 11 ressemble à celle de Chrome, sauf qu'elle répertorie explicitement le code global : 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:3)
  at Global code (http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3)

La trace de la pile de Firefox ressemble à : 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9
  @http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Le format de Safari est similaire à celui de Firefox mais est également légèrement différent : 

  throwError@http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:18
  global code@http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:13

Les mêmes informations de base sont présentes, mais le format est différent.

Notez également que dans l'exemple Safari, outre le format différent de celui de Chrome, les numéros de colonne sont différents de ceux de Chrome et de Firefox. Les numéros de colonnes peuvent également différer davantage dans différentes situations d'erreur - par exemple dans le code (function namedFunction() { throwError(); })(); , Chrome signalera la colonne pour l'appel de fonction throwError() tandis qu'IE11 signalera le numéro de colonne comme début de la chaîne. Ces différences reviendront en jeu plus tard lorsque le serveur devra analyser la trace de pile pour détecter les erreurs signalées et désobscurcir les traces de pile obscurcies.

Voir https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/Stack pour plus d'informations sur la propriété de pile des erreurs. Lors de l'accès à la propriété Error.stack, Chrome inclut le message d'erreur dans la pile, mais pas Safari 10+.

Le format des traces de pile est différent selon le navigateur en termes de forme et de numéros de colonnes utilisés.

En approfondissant davantage, il existe de nombreuses nuances pour empiler les formats de trace qui sont abordées dans les sections ci-dessous.

Nommer des fonctions anonymes

Par défaut, les fonctions anonymes n'ont pas de nom et apparaissent soit sous forme de chaîne vide, soit sous forme de "Fonction anonyme" dans les noms de fonctions dans la trace de la pile (selon le navigateur). Pour améliorer le débogage, vous devez ajouter un nom à toutes les fonctions pour garantir qu'elles apparaissent dans le cadre de la pile. Le moyen le plus simple de procéder consiste à garantir que les fonctions anonymes sont spécifiées avec un nom, même si ce nom n'est utilisé nulle part ailleurs. Par exemple:

 setTimeout(function nameOfTheAnonymousFunction() { ... }, 0);

Cela fera passer la trace de la pile de : 

at http://mknichel.github.io/javascript-errors/javascript-errors.js:125:17

à 

at nameOfTheAnonymousFunction (http://mknichel.github.io/javascript-errors/javascript-errors.js:121:31)

Dans Safari, cela viendrait de : 

https://mknichel.github.io/javascript-errors/javascript-errors.js:175:27

à 

nameOfTheAnonymousFunction@https://mknichel.github.io/javascript-errors/javascript-errors.js:171:41

Cette méthode garantit que nameOfTheAnonymousFunction apparaît dans le cadre de tout code provenant de cette fonction, ce qui rend le débogage beaucoup plus facile. Voir http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/#toc-debugging-tips pour plus d'informations.

Affectation de fonctions à une variable

Les navigateurs utiliseront également le nom de la variable ou de la propriété à laquelle une fonction est affectée si la fonction elle-même n'a pas de nom. Par exemple, dans

 var fnVariableName = function() { ... };

les navigateurs utiliseront fnVariableName comme nom de la fonction dans les traces de pile. 

    at throwError (http://mknichel.github.io/javascript-errors/javascript-errors.js:27:9)
    at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

Plus nuancé encore, si cette variable est définie au sein d'une autre fonction, tous les navigateurs utiliseront uniquement le nom de la variable comme nom de la fonction dans la trace de la pile sauf Firefox, qui utilisera une forme différente qui concatène le nom de la fonction externe avec le nom de la variable interne. Exemple:

 fonction throwErrorFromInnerFunctionAssignedToVariable() {
  var fnVariableName = function() { throw new Error("foo"); } ;
  fnVariableName();}

produira dans Firefox : 

throwErrorFromInnerFunctionAssignedToVariable/fnVariableName@http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37

Dans d'autres navigateurs, cela ressemblerait à : 

at fnVariableName (http://mknichel.github.io/javascript-errors/javascript-errors.js:169:37)

Firefox utilise un texte de cadre de pile différent pour les fonctions définies dans une autre fonction.

Propriété displayName

Le nom d'affichage d'une fonction peut également être défini par la propriété displayName dans tous les principaux navigateurs à l'exception d'IE11. Dans ces navigateurs, le displayName apparaîtra dans le débogueur devtools, mais dans tous les navigateurs sauf Safari, il ne sera pas utilisé dans les traces de pile d'erreurs (Safari diffère des autres en utilisant également le displayName dans la trace de pile associée à une erreur).

 var someFunction = function() {};someFunction.displayName = " # Une description plus longue de la fonction.";

Il n'existe pas de spécification officielle pour la propriété displayName, mais elle est prise en charge par tous les principaux navigateurs. Voir https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/displayName et http://www.alertdebugging.com/2009/04/29/building-a-better -javascript-profiler-with-webkit/ pour plus d'informations sur displayName.

IE11 ne prend pas en charge la propriété displayName.

Safari utilise la propriété displayName comme nom de symbole dans les traces de la pile d'erreurs.

Capturer par programme les traces de pile

Si une erreur est signalée sans trace de pile (voir plus de détails ci-dessous), il est alors possible de capturer par programme une trace de pile.

Dans Chrome, cela est très simple à faire en utilisant l'API Error.captureStackTrace . Voir https://github.com/v8/v8/wiki/Stack%20Trace%20API pour plus d'informations sur l'utilisation de cette API.

Par exemple:

 fonction ignoreThisFunctionInStackTrace() {
  var err = nouvelle erreur ();
  Error.captureStackTrace(err, ignoreThisFunctionInStackTrace);
  renvoie err.stack;}

Dans d'autres navigateurs, une trace de pile peut également être collectée en créant une nouvelle erreur et en accédant à la propriété de pile de cet objet :

 var err = new Error('');return err.stack;

Cependant, IE10 ne remplit la trace de la pile que lorsque l'erreur est réellement générée :

 essayer {
  throw new Error('');} catch (e) {
  retourner e.stack ;}

Si aucune de ces approches ne fonctionne, il est alors possible de créer une trace de pile approximative sans numéros de ligne ni colonnes en itérant sur l'objet arguments.callee.caller - cela ne fonctionnera cependant pas en mode strict ES5 et ce n'est pas une approche recommandée.

Traces de pile asynchrone

Il est très courant que des points asynchrones soient insérés dans le code JavaScript, par exemple lorsque le code utilise setTimeout ou via l'utilisation de Promises. Ces points d'entrée asynchrones peuvent poser des problèmes pour les traces de pile, car ils provoquent la formation d'un nouveau contexte d'exécution et la trace de pile recommence à zéro.

Chrome DevTools prend en charge les traces de pile asynchrone, ou en d'autres termes, s'assure que la trace de pile d'une erreur affiche également les images qui se sont produites avant l'introduction du point asynchrone. Avec l'utilisation de setTimeout, cela permettra de capturer qui a appelé la fonction setTimeout qui a finalement produit une erreur. Voir http://www.html5rocks.com/en/tutorials/developertools/async-call-stack/ pour plus d'informations.

Une trace de pile asynchrone ressemblera à : 

  throwError	@	throw-error.js:2
  setTimeout (async)		
  throwErrorAsync	@	throw-error.js:10
  (anonymous function)	@	throw-error-basic.html:14

Les traces de pile asynchrone ne sont actuellement prises en charge que dans Chrome DevTools, uniquement pour les exceptions levées lorsque les DevTools sont ouverts. Les traces de pile accessibles à partir des objets Error dans le code ne contiendront pas la trace de pile asynchrone.

Il est possible de polyfiller les traces de pile asynchrones dans certains cas, mais cela pourrait entraîner une baisse significative des performances de votre application, car la capture d'une trace de pile n'est pas bon marché.

Seul Chrome DevTools prend en charge nativement les traces de pile asynchrone.

Nommer les scripts en ligne et les évaluations

Les traces de pile pour le code qui a été évalué ou intégré dans une page HTML utiliseront l'URL de la page et les numéros de ligne/colonne pour le code exécuté.

Par exemple: 

  at throwError (http://mknichel.github.io/javascript-errors/throw-error-basic.html:8:9)
  at http://mknichel.github.io/javascript-errors/throw-error-basic.html:12:3

Si ces scripts proviennent en réalité d'un script qui a été intégré pour des raisons d'optimisation, alors les numéros d'URL, de ligne et de colonne seront erronés. Pour contourner ce problème, Chrome et Firefox prennent en charge l'annotation //# sourceURL= (ce qui n'est pas le cas de Safari, Edge et IE). L'URL spécifiée dans cette annotation sera utilisée comme URL pour toutes les traces de pile, et le numéro de ligne et de colonne sera calculé par rapport au début de la balise