Introduction à la gestion des erreurs en Javascript et Typescript

By Gary Gitton|Posted 07 Jun, 2022

Introduction à la gestion des erreurs en Javascript et Typescript

En tant que développeur, vous rencontrerez des bug dans les fonctionnalités de votre application. 

Lorsque cela se produit, vous devez vous y préparer et savoir quoi faire. En effet, une bonne gestion des erreurs est à la fois cruciale pour les utilisateurs de votre application et pour les développeurs qui interviennent sur le projet.

Dans cette article, nous allons brièvement nous intéresser aux possibilités offertes par JavaScript aux développeurs afin de traiter des erreurs.

On peut utiliser en JavaScript la classe Erreur pour lever des exceptions dans un bloc try/catch et l’utilisation du mot-clé throw :

Il existe différents sous-types d’erreurs, notamment :

  • RangeError : lorsqu’il y a un problème avec une valeur numérique, qui se situe hors de l’intervalle de validité.
 
  • SynthaxError : lorsque le code n’est pas du Javascript valide.
 
  • InternalError : une erreur “interne” au moteur JavaScript.
 
  • URI Error : lorsqu’un mauvais paramètre est passé à encodeURI() ou decodeURI().

L’utilisation de la classe Error 

La classe Error et throw : 

Il y a deux cas d’utilisation :

  • L’utilisation du mot clé “throw” avec un objet de type Error. Dans ce cas, l’erreur est une exception. Le bloc de code susceptible de renvoyer une exception est considéré comme “risqué” à l’exécution, et devra être contenu dans un bloc try/catch.
 
  • L’utilisateur d’un objet Error seul, ou tout autre objet. Dans ce cas, il s’agira d’une simple erreur.
 

Il est recommandé de toujours utiliser des objets de type Error et non des chaînes de caractères.

Le code ci-dessous est donc déconseillé, car l’avantage d’utiliser un objet de type Error est qu’il permet de garder une trace concernant leur origine et où elles sont susceptibles de se produire :

Il n’est pas toujours nécéssaire d’utiliser throw 

Avec Node JS, les erreurs peuvent être passées et utilisées dans des callbacks.

Par exemple :

Certains problèmes liés à l’utilisation des exceptions 

L’utilisation des exceptions devrait être exceptionnelle, car elles peuvent rendre le code illisible et imprévisible. 

Ambiguïté de l’origine où l’exécution est lévée 

Prenons par exemple cet extrait de code :

Il n’est pas possible de déterminer quelle fonction est susceptible de lever une exception.

Cela peut devenir difficile à lire…

Le problème mentionné ci-dessus peut être éliminé simplement comme ça :

Mais dans le cas où il faut transmettre des données, par exemple les données de la tâche n°1 à la tâche n°2, la compréhension du code devient compliquée.

Les types sont mal représentés 

Considérons la fonction suivante :

Le renvoi d’un objet Erreur (RangeError ou TypeError ici) avec un throw est une mauvaise idée ici, car la signature de la fonction sera alors mal représentée ( (value:number) => number )). 

Autrement dit, elle n’indique pas que la fonction computeBetween0And10 peut lever des exceptions.

En revanche, pour l’exemple suivant : la signature de la fonction sera de type (value:number) => number | RangeError | TypeError, ce qui permettra aux utilisateurs de la fonction d’avoir une meilleure compréhension du comportement de la fonction.

La gestion des erreurs simple en JavaScript 

Le déclenchement d’erreur générique

Comme montrée précédemment, on pourra utiliser le mot-clé throw pour déclencher une erreur générique :

Gestion d’erreur spécifique 

L’utilisation du mot-clé instanceof permet de vérifier le type d’erreur. Il pourra être utilisé dans le bloc catch.

Création de type d’erreurs personnalisés 

Il est possible de créer des types d’erreurs personnalisés, dérivant du type Error pour pouvoir écrire throw new MonErreur() et utiliser instanceof MonErreur.

Il pourra être utilisé par la suite :

Selon que l’on utilise ES6 seul ou avec certains transpilers, cela peut poser des problèmes :

On peut pallier à ce problème en utilisant la méthode statique setPrototypeOf :

Conclusion

JavaScript est assez permissif quant au traitement des erreurs. 

Mais cela implique de penser en amont la manière dont elles devront être traitées et implémentées sur un projet de taille raisonnable.

Leave a Reply

Your email address will not be published. Required fields are marked *