qu’est-Ce que une erreur dans la programmation?

les Choses ne vont pas toujours bien dans nos programmes.

en particulier, il y a des situations où nous pouvons vouloir arrêter le programme ou informer l’utilisateur si quelque chose de mauvais se produit.

Par exemple:

  • le programme a essayé d’ouvrir un fichier inexistant.
  • la connexion réseau est interrompue.
  • l’utilisateur a entré une entrée non valide.,

dans tous ces cas, nous, programmeurs, créons des erreurs, ou nous laissons le moteur de programmation en créer pour nous.

Après avoir créé l’erreur, nous pouvons informer l’utilisateur avec un message, ou nous pouvons arrêter complètement l’exécution.

Qu’est-ce qu’une erreur dans JavaScript?

Une erreur dans JavaScript est un objet, qui est ensuite lancé pour arrêter le programme.

pour créer une nouvelle erreur en JavaScript, nous appelons la fonction constructeur appropriée., Par exemple, pour créer une nouvelle erreur générique que nous pouvons faire:

const err = new Error("Something bad happened!");

Lors de la création d’un objet d’erreur, il est également possible d’omettre la balise new mot clé:

const err = Error("Something bad happened!");

une Fois créé, l’objet d’erreur présente trois propriétés:

  • message: une chaîne de caractères avec le message d’erreur.
  • name: le type de l’erreur.
  • stack: une trace de la pile des fonctions d’exécution.,

par exemple, si nous créons un nouvel objet TypeError avec le message approprié, le message portera la chaîne d’erreur réelle, tandis que name sera "TypeError":

Firefox implémente également un tas de propriétés non standard comme columnNumber, filename et lineNumber.,

Many types of errors in JavaScript

There are many types of errors in JavaScript, namely:

  • Error
  • EvalError
  • InternalError
  • RangeError
  • ReferenceError
  • SyntaxError
  • TypeError
  • URIError

Remember, all these error types are actual constructor functions meant to return a new error object.,

Dans votre code, vous aurez surtout à utiliser Error et TypeError, deux des types les plus courants, pour créer votre propre objet d’erreur.

la Plupart du temps, la plupart des erreurs viennent directement du moteur JavaScript, comme InternalError ou SyntaxError., 

va x = '33';// SyntaxError: Unexpected identifier

Ou lorsque vous utilisez des mots clés réservés dans les mauvais endroits, comme await en dehors d’un async fonction:

function wrong(){ await 99;}wrong();// SyntaxError: await is only valid in async function

un Autre exemple de TypeError se produit lorsque l’on sélectionne inexistante éléments HTML dans la page:

Uncaught TypeError: button is null

En plus de ces traditionnels objets d’erreur, un AggregateError objet est sur le point de débarquer bientôt en JavaScript., AggregateError est pratique pour encapsuler plusieurs erreurs ensemble, comme nous le verrons plus tard.

en plus de ces erreurs, dans le navigateur, nous pouvons trouver aussi:

  • DOMException.
  • DOMError, obsolète et n’est plus utilisé aujourd’hui.

DOMException est une famille d’erreurs liées à l’Api Web., Ils sont jetés quand nous faisons des choses stupides dans le navigateur, par exemple:

document.body.appendChild(document.cloneNode(true));

Le résultat:

Uncaught DOMException: Node.appendChild: May not add a Document as a child

Pour une liste complète, voir cette page sur MDN.

qu’est-ce qu’une exception?

la plupart des développeurs pensent que l’erreur et les exceptions sont la même chose. En réalité, un objet d’erreur ne devient une exception que lorsqu’il est lancé.,

Pour lancer une exception en JavaScript on utilise throw, suivie par l’objet d’erreur:

const wrongType = TypeError("Wrong type given, expected number");throw wrongType;

La forme courte est la plus courante dans la plupart des bases de code, vous trouverez:

throw TypeError("Wrong type given, expected number");

ou

throw new TypeError("Wrong type given, expected number");

Il est peu probable que de lancer des exceptions à l’extérieur d’une fonction ou d’un bloc conditionnel. Considérez plutôt l’exemple suivant:

ici, nous vérifions si l’argument de la fonction est une chaîne., Si ce n’est pas le cas, nous lançons une exception.

Techniquement, vous pourriez jeter quoi que ce soit en JavaScript, pas seulement des objets d’erreur:

throw Symbol();throw 33;throw "Error!";throw null;

Cependant, il est préférable d’éviter ces choses: toujours jeter erreur approprié des objets, pas des primitives.

ce faisant, vous gardez la gestion des erreurs cohérente via la base de code. D’autres membres de l’équipe peuvent toujours s’attendre à l’accès error.message ou error.stack sur l’objet d’erreur.

que se passe – t-il lorsque nous lançons une exception?,

Les Exceptions sont comme un ascenseur qui monte: une fois que vous en lancez un, il fait des bulles dans la pile du programme, à moins qu’il ne soit pris quelque part.

Considérons le code suivant:

Si vous exécutez ce code dans un navigateur ou dans le Nœud.js, le programme s’arrête et signale l’erreur:

En outre, vous pouvez voir exactement la ligne où l’erreur s’est produite.

ce rapport est une trace de pile, et il est utile pour traquer les problèmes dans votre code.

la trace de la pile va de bas en haut., Donc ici:

 toUppercase http://localhost:5000/index.js:3 <anonymous> http://localhost:5000/index.js:9

On peut dire:

  • quelque chose dans le programme à la ligne 9 appelé toUppercase
  • toUppercase a soufflé jusqu’à la ligne 3

En plus de voir cette trace de la pile dans le navigateur de la console, vous pouvez y accéder sur le stack propriété de l’objet d’erreur.

Si l’exception est interceptée, qui est, rien n’est fait par le programmeur de l’attraper, le programme plantera.,

Quand et où vous intercepter une exception dans votre code dépend du cas d’utilisation spécifiques.

par exemple, vous pouvez propager une exception dans la pile pour planter complètement le programme. Cela peut se produire pour des erreurs fatales, quand il est plus sûr d’arrêter le programme plutôt que de travailler avec des données invalides.

Après avoir introduit les bases, tournons maintenant notre attention sur la gestion des erreurs et des exceptions dans le code JavaScript synchrone et asynchrone.

Synchrones gestion d’erreur

code Synchrone est la plupart du temps simple, et donc sa gestion des erreurs.,

gestion des erreurs pour les fonctions régulières

le code synchrone est exécuté dans le même ordre dans lequel est écrit. Reprenons l’exemple précédent:

Ici, le moteur appelle et exécute toUppercase. Tout se passe de façon synchrone. Pour attraper une exception provenant par exemple de fonction synchrone, nous pouvons utiliser try/catch/finally:

try { toUppercase(4);} catch (error) { console.error(error.message); // or log remotely} finally { // clean up}

Généralement, try traite avec le chemin d’accès joyeux, ou avec l’appel de fonction qui pourrait lancer.,

catch à la place, capture l’exception réelle. Il reçoit l’objet d’erreur, que nous pouvons inspecter (et envoyer à distance à un enregistreur en production).

l’instruction finallyd’autre part s’exécute quel que soit le résultat de la fonction: qu’elle ait échoué ou réussi, tout code à l’intérieur de finally s’exécutera.

rappelez-vous:try/catch/finally est une construction synchrone: il a maintenant moyen d’attraper les exceptions provenant du code asynchrone.,

gestion des erreurs pour les fonctions de générateur

Une fonction de générateur en JavaScript est un type spécial de fonction.

Il peut être mis en pause et repris à volonté, autre que de fournir un canal de communication bidirectionnel entre sa portée interne et le consommateur.,

Pour créer un générateur de fonction nous mettre une étoile * après le function mot clé:

function* generate() {//}

une Fois à l’intérieur de la fonction, nous pouvons utiliser yield pour les valeurs de retour:

function* generate() { yield 33; yield 99;}

La valeur de retour à partir d’un générateur de fonction est un itérateur de l’objet. Pour extraire des valeurs d’un générateur, nous pouvons utiliser deux approches:

  • appelant next() sur l’objet itérateur.,
  • itération avec des for...of.

Si nous prenons notre exemple, pour obtenir des valeurs du générateur que nous pouvons faire:

function* generate() { yield 33; yield 99;}const go = generate();

Ici go devient notre itérateur objet quand on appel la fonction de générateur.

a Partir de maintenant, nous pouvons l’appeler go.next() à l’avance de l’exécution:

function* generate() { yield 33; yield 99;}const go = generate();const firstStep = go.next().value; // 33const secondStep = go.next().value; // 99

Générateurs également travailler dans l’autre sens: ils peuvent accepter des valeurs et des exceptions de retour de l’appelant.,

en plus denext(), les objets itérateurs renvoyés par les générateurs ont une méthodethrow().

Avec cette méthode, nous pouvons stopper le programme en injectant une exception dans le générateur:

Pour attraper erreur vous enveloppez votre code à l’intérieur du générateur avec des try/catch (et finally si nécessaire):

function* generate() { try { yield 33; yield 99; } catch (error) { console.error(error.message); }}

Générateur de fonctions peuvent également lancer des exceptions à l’extérieur., Le mécanisme pour attraper ces exceptions est le même pour attraper les exceptions synchrones: try/catch/finally.

Voici un exemple de fonction génératrice consommée de l’extérieur avecfor...of:

ici, nous itérons le chemin heureux à l’intérieur d’un bloctry. Si des exceptions se produisent, nous l’arrêtons avec catch.

gestion des erreurs asynchrones

JavaScript est synchrone par nature, étant un langage à un seul thread.,

les environnements hôtes tels que les moteurs de navigateurs augmentent JavaScript avec un certain nombre D’API Web pour interagir avec des systèmes externes et pour gérer les opérations liées aux E / S.

des exemples d’asynchronicité dans le navigateur sont timeouts, events, Promise.

la gestion des erreurs dans le monde asynchrone est distincte de son homologue synchrone.

nous allons voir quelques exemples.

gestion des erreurs pour les minuteries

Au début de vos explorations avec JavaScript, après avoir découverttry/catch/finally, vous pourriez être tenté de le mettre autour de n’importe quel bloc de code.,

Considérons le fragment de code suivant:

function failAfterOneSecond() { setTimeout(() => { throw Error("Something went wrong!"); }, 1000);}

Cette fonction lance après environ 1 seconde. Quelle est la bonne façon de gérer cette exception?

L’exemple suivant ne fonctionne pas:

Comme nous l’avons dit, try/catch est synchrone. D’autre part, nous avons setTimeout, une API de navigateur pour les minuteries.

au moment où le callback passé à setTimeout s’exécute, notre try/catch est révolue depuis longtemps. Le programme va planter parce que nous n’avons pas réussi à capturer l’exception.,

Ils voyagent sur deux pistes différentes:

Track A: --> try/catchTrack B: --> setTimeout --> callback --> throw

Si nous ne voulons pas planter le programme, pour gérer l’erreur correctement, nous devons aller de try/catch à l’intérieur de la fonction de rappel pour l’ setTimeout.

Mais, cette approche n’a pas beaucoup de sens la plupart du temps. Comme nous le verrons plus tard, la gestion des erreurs asynchrones avec Promises offre une meilleure ergonomie.,

gestion des erreurs pour les événements

Les nœuds HTML du modèle D’objet Document sont connectés àEventTarget, l’ancêtre commun pour tout émetteur d’événement dans le navigateur.

cela signifie que nous pouvons écouter les événements sur n’importe quel élément HTML de la page.

(nœud.js prendra en charge EventTarget dans une version future).

la mécanique de gestion des erreurs pour les événements DOM suit le même schéma que toute API Web asynchrone.

prenons l’exemple suivant:

Ici, nous jeter une exception dès que le bouton est cliqué. Comment l’attraper?, Ce modèle ne fonctionne pas et n’empêchera pas le programme de planter:

comme avec l’exemple précédent avec setTimeout, tout rappel passé à addEventListener est exécuté de manière asynchrone:

Track A: --> try/catchTrack B: --> addEventListener --> callback --> throw

si nous ne voulons pas planter le programme, pour gérer l’erreur correctement, nous devons déplacer try/catch dans le rappel pour addEventListener.

mais encore une fois, il y a peu de valeur à faire cela.,

comme avecsetTimeout, les exceptions lancées par un chemin de code asynchrone ne peuvent pas être capturées de l’extérieur et planteront votre programme.

dans les sections suivantes, nous verrons comment les promesses etasync/await peuvent faciliter la gestion des erreurs pour le code asynchrone.

Que diriez-vous de onerror?

les éléments HTML ont un certain nombre de gestionnaires d’événements comme onclick, onmouseenter, onchange pour n’en nommer que quelques-unes.

Il y a aussi onerror, mais il n’a rien à voir avec des throw et amis.,

Le onerror gestionnaire d’événement feux de tout temps un élément HTML comme un <img> balise ou un <script> frappe inexistante de ressources.,b4″>// omitted<body><img src="https://www.valentinog.com/blog/error/nowhere-to-be-found.png" alt="So empty!"></body>// omitted

Lors de la visite d’un document HTML avec un manquant ou inexistant des ressources du navigateur de la console enregistre l’erreur:

GET http://localhost:5000/https://www.valentinog.com/blog/error/nowhere-to-be-found.png

Dans notre JavaScript, nous avons la chance de « rattraper » cette erreur avec le gestionnaire d’événement approprié:

const image = document.querySelector("img");image.onerror = function(event) { console.log(event);};

Ou mieux:

const image = document.querySelector("img");image.addEventListener("error", function(event) { console.log(event);});

Ce modèle est utile pour le chargement d’autres ressources, à la place des images manquantes ou des scripts.,

Mais n’oubliez pas: onerror, n’a rien à voir avec des throw ou try/catch.

gestion des erreurs avec Promise

pour illustrer la gestion des erreurs avec Promise, nous allons « promisifier » l’un de nos exemples originaux. Nous modifions la fonction suivante:

Au Lieu de renvoyer une simple chaîne, ou une exception, nous utilisons respectivement Promise.rejectEt Promise.resolve pour gérer l’erreur et le succès:

(techniquement, il n’y a rien d’asynchrone dans ce code, mais il sert bien,

Maintenant que la fonction est « promisified » nous pouvons mettre un then pour consommer le résultat, et catch pour la gestion de l’rejeté Promesse:

toUppercase(99) .then(result => result) .catch(error => console.error(error.message));

Ce code journal:

Wrong type given, expected a string

Dans le domaine de la Promesse, catch est la construction pour les erreurs de manipulation.,

En plus catch et then nous avons aussi finally, similaire à la balise finally dans un try/catch.

en tant que « relatif » synchrone, le finally s’exécute quel que soit le résultat de la promesse:

toUppercase(99) .then(result => result) .catch(error => console.error(error.message)) .finally(() => console.log("Run baby, run"));

gardez toujours à l’esprit que tout rappel passé à then/catch/finally est géré de manière asynchrone par la file d’attente microtask. Ce sont des micro-tâches avec priorité sur les tâches de macro telles que les événements et les minuteries.,

Promise, error et throw

en tant que meilleure pratique lors du rejet d’une promesse, il est pratique de fournir un objet error: 

Promise.reject(TypeError("Wrong type given, expected a string"));

en faisant cela, vous gardez la gestion des erreurs cohérente via la base de code. Les autres membres de l’équipe peuvent toujours s’attendre à accéder à error.message, et plus important encore, vous pouvez inspecter les traces de pile.

en plus dePromise.reject, nous pouvons sortir d’une chaîne de promesses en lançant une exception.,

prenons l’exemple suivant:

Promise.resolve("A string").then(value => { if (typeof value === "string") { throw TypeError("Expected a number!"); }});

Nous résoudre une Promesse avec une chaîne et la chaîne est immédiatement rompu avec throw.

Pour arrêter la propagation d’exception, nous utilisons la balise catch, comme d’habitude:

Ce motif est fréquent dans fetch, où nous vérifions l’objet de la réponse à la recherche pour les erreurs:

Ici, l’exception peut être intercepté par catch., Si nous échouons, ou décider de ne pas l’attraper là, l’exception est libre de remonter dans la pile.

ce n’est pas mauvais en soi, mais différents environnements réagissent différemment aux rejets non interceptés.

nœud.js par exemple à l’avenir laissera planter tout programme où les rejets de promesses ne sont pas gérés:

DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

mieux vaut les attraper!

gestion des erreurs pour les minuteries « promises »

avec des minuteries ou des événements, il n’est pas possible d’attraper des exceptions levées à partir d’un rappel., Nous avons vu un exemple dans la section précédente:

Une solution proposée par Promise consiste en la « promisification » de notre code. Fondamentalement, nous terminons notre timer avec une Promesse:

function failAfterOneSecond() { return new Promise((_, reject) => { setTimeout(() => { reject(Error("Something went wrong!")); }, 1000); });}

Avec des reject nous avons une Promesse de rejet, qui comporte une erreur de l’objet.,

À ce stade, nous pouvons gérer l’exception avec des catch:

failAfterOneSecond().catch(reason => console.error(reason.message));

Note: il est courant d’utiliser la balise value le retour de la valeur d’une Promesse, et reason comme le retour de l’objet d’un rejet.

nœud.js a un utilitaire appelé promisify pour faciliter la » promisification  » des API de rappel à l’ancienne.

gestion des erreurs dans Promise.,tous

La méthode statique Promise.all accepte un tableau de la Promesse, et retourne un tableau des résultats de tous les résoudre Promesse:

Si l’un de ces Promesses rejette, Promise.all rejette avec l’erreur de la première rejeté Promesse.

Pour gérer ces situations dans Promise.all nous utilisons la balise catch, comme nous l’avons fait dans la section précédente:

Pour exécuter une fonction quel que soit le résultat de Promise.all, encore une fois, on peut utiliser finally:

Erreur de manipulation de la Promesse.,tout

On peut considérer Promise.any (Firefox > 79, Chrome > 85) comme le contraire de Promise.all.

alors quePromise.all renvoie un échec même si une seule promesse dans le tableau est rejetée,Promise.any nous donne toujours la première promesse résolue (si elle est présente dans le tableau) quel que soit le rejet.

dans le cas où à la place toute la promesse passée àPromise.anyrejeter, l’erreur résultante est unAggregateError., Considérons l’exemple suivant:

Ici, nous nous occupons de l’erreur avec catch., La sortie de ce code est:

AggregateError: No Promise in Promise.any was resolvedAlways runs!

Le AggregateError objet possède les mêmes propriétés de base d’un Error, en plus d’un errors propriété:

// .catch(error => console.error(error.errors))//

Cette propriété est un tableau de chaque erreur produite par le rejeter:

Erreur de manipulation de la Promesse.,course

La méthode statique Promise.race accepte un tableau de la Promesse:

Le résultat est la première Promesse qui gagne la « race ».

Que diriez-vous des rejets alors? Si la promesse de rejet n’est pas la première à apparaître dans le tableau d’entrée, Promise.race résout:

Si le rejet apparaît à la place comme le premier élément du tableau, Promise.race rejette, et nous devons attraper le rejet:

gestion des erreursallSettled

Promise.allSettled est un ajout ECMAScript 2020 au langage.,

Il n’y a pas tellement de choses à gérer avec cette méthode statique car le résultat sera toujours une promesse résolue, même si une ou plusieurs promesses d’entrée sont rejetées.

prenons l’exemple suivant:

nous passons à Promise.allSettled un tableau composé de deux promesses: une résolue et une autre rejetée.

Dans ce cas catch ne sera jamais frappé. finally s’exécute à la place.,

le résultat de ce code, connecté then est:

gestion des erreurs pour async/await

async/await en JavaScript désigne les fonctions asynchrones, mais du point de vue du lecteur, elles bénéficient de toute la lisibilité des fonctions synchrones.,

pour garder les choses simples, nous prendrons notre fonction synchrone précédente toUppercase, et nous la transformerons en une fonction asynchrone en mettant async avant le mot-clé function:

juste en préfixant une fonction avec async nous faisons en sorte que la fonction renvoie une promesse., Cela signifie que nous pouvons enchaîner then, catch Et finally après l’appel de fonction:

lorsque nous lançons à partir d’une fonction async, l’exception devient cause de rejet de la promesse sous-jacente.

Toute erreur peut être intercepté par catch de l’extérieur.

le Plus important, en plus de ce style, nous pouvons utiliser try/catch/finally, un peu comme on le ferait avec une fonction synchrone.,

Dans l’exemple suivant nous appelons toUppercase partir d’une autre fonction, consumer, idéalement encapsule l’appel de la fonction avec try/catch/finally:

La sortie est:

Wrong type given, expected a stringAlways runs!

Sur le même sujet: Comment générer des Erreurs De Async des Fonctions en JavaScript?

gestion des erreurs pour les générateurs asynchrones

Les générateurs asynchrones en JavaScript sont des fonctions de générateur capables de donner des promesses au lieu de simples valeurs.,

ils combinent des fonctions de générateur avecasync. Le résultat est une fonction génératrice dont les objets itérateurs exposent une promesse au consommateur.

pour créer un générateur asynchrone, nous déclarons une fonction de générateur avec l’étoile *, préfixée par async:

async function* asyncGenerator() { yield 33; yield 99; throw Error("Something went wrong!"); // Promise.reject}

étant basé sur promise, les mêmes règles de gestion des erreurs s’appliquent ici., throw à l’intérieur d’un générateur asynchrone provoque un rejet de promesse, que nous interceptons avec catch.

pour extraire les promesses d’un générateur asynchrone, nous pouvons utiliser deux approches:

  • then gestionnaires.
  • itération asynchrone.

Dans l’exemple ci-dessus, nous savons pour sûr qu’il y aura une exception, après les deux premiers yield., Cela signifie que nous pouvons faire:

La sortie de ce code est:

{ value: 33, done: false }{ value: 99, done: false }Something went wrong!

L’autre approche utilise async itération avec des for await...of. Pour utiliser l’itération asynchrone, nous devons envelopper le consommateur avec une fonction async.,

Voici l’exemple complet:

Et comme async/await nous nous occupons de tout le potentiel d’exception avec des try/catch:

La sortie de ce code est:

3399Something went wrong!

L’itérateur de l’objet retourné par une fonction du générateur asynchrone a aussi un throw() méthode, tout comme son synchrone homologue.,

Appeler throw() sur l’itérateur objet ici n’est pas de générer une exception, mais une Promesse de rejet:

Pour gérer cette situation à partir de l’extérieur, nous pouvons faire:

go.throw(Error("Let's reject!")).catch(reason => console.error(reason.message));

Mais n’oublions pas que l’itérateur objets throw() envoyer l’exception à l’intérieur du générateur. Cela signifie que nous pouvons également appliquer le modèle suivant:

gestion des erreurs dans Node.js

gestion synchrone des erreurs dans le nœud.js

gestion synchrone des erreurs dans le nœud.,js ne diffère pas trop de ce que nous avons vu jusqu’à présent.

pour le code synchrone,try/catch/finally fonctionne correctement.

cependant, les choses deviennent intéressantes si nous jetons un coup d’œil au monde asynchrone.

gestion des erreurs asynchrones dans le nœud.js: le modèle de rappel

pour le code asynchrone, Node.js s’appuie fortement sur deux idiomes:

  • le modèle de rappel.
  • émetteurs d’événements.

dans le modèle de rappel, nœud asynchrone.les API js acceptent une fonction qui est gérée via la boucle d’événements et exécutée dès que la pile d’appels est vide.,

considérez le code suivant:

Si nous extrayons le rappel de cette liste, nous pouvons voir comment il est censé traiter les erreurs:

//function(error, data) { if (error) console.error(error); // do stuff with the data }//

Si des erreurs surviennent lors de la lecture du chemin donné avec fs.readFile, nous obtenons un objet d’erreur.

À ce stade, nous pouvons:

  • il suffit de connecter l’objet d’erreur comme nous l’avons fait.
  • lancer une exception.
  • transmettez l’erreur à un autre rappel.,

pour lancer une exception, nous pouvons faire:

cependant, comme pour les événements et les minuteries dans le DOM, cette exception Plantera le programme. La tentative suivante de l’arrêter avec try/catch ne fonctionnera pas:

passer l’erreur à un autre rappel est l’option préférée, si nous ne voulons pas planter le programme:

ici errorHandler est ce que son nom suggère, une fonction simple pour la gestionjs: event emitters

Une grande partie de ce que vous faites dans Node.js est basé sur des événements., La plupart du temps, vous interagissez avec un objet émetteur et certains observateurs écoutent des messages.

tout module piloté par un événement (comme net par exemple) dans Node.js étend une classe racine nommée EventEmitter.

EventEmitter dans le Nœud.js a deux méthodes fondamentales: on et emit.

considérez ce serveur HTTP simple:

ici, nous écoutons deux événements: l’écoute et la connexion.

En plus de ces événements, l’événement émetteurs exposer aussi un événement d’erreur, déclenché en cas d’erreurs.,

Si vous exécutez ce code à l’écoute sur le port 80 au lieu de l’exemple précédent, vous aurez une exception:

Résultat:

Pour l’attraper, nous pouvons enregistrer un gestionnaire d’événements pour l’erreur:

server.on("error", function(error) { console.error(error.message);});

Cela permettra d’imprimer:

listen EACCES: permission denied 127.0.0.1:80

En outre, le programme ne plante pas.

pour en savoir plus sur le sujet, pensez également à lire « gestion des erreurs dans Node.js ».,

conclusion

dans ce guide, nous avons couvert la gestion des erreurs en JavaScript pour L’ensemble du spectre, du simple code synchrone aux primitives asynchrones avancées.

Il existe de nombreuses façons dont une exception peut se manifester dans nos programmes JavaScript.

Les Exceptions du code synchrone sont les plus simples à attraper. Les Exceptions des chemins de code asynchrones peuvent être difficiles à gérer.

En attendant, les nouvelles API JavaScript dans le navigateur sont presque toutes dirigées versPromise., Ce modèle omniprésent facilite la gestion des exceptions avec then/catch/finally, ou avec try/catch pour async/await.

Après avoir lu ce guide, vous devriez être en mesure de reconnaître toutes les différentes situations qui peuvent survenir dans vos programmes, et attraper vos exceptions correctement.

Merci d’avoir lu et restez à l’écoute!

Ce message est également disponible en:

  • Japonais
  • Chinois