‫Jonas : Dans cette vidéo,
‫nous allons implémenter une logique afin d'envoyer différents messages
‫d'erreur pour l'environnement de développement et de production.
‫Donc en ce moment, nous envoyons ce même message de réponse ici essentiellement
‫à tout le monde, peu importe si nous sommes en
‫développement ou en production.
‫Mais l'idée est qu'en production, nous voulons divulguer
‫le moins d'informations possible sur
‫nos erreurs au client.
‫Donc, dans ce cas, nous voulons seulement
‫envoyer un message agréable et
‫convivial pour que l'utilisateur sache ce qui ne va pas.
‫D'un autre côté, lors du
‫développement écrit, nous voulons obtenir autant d'informations que possible sur
‫l'erreur qui s'est produite, et nous voulons que cela
‫soit directement dans le message d'erreur qui revient.
‫Nous pourrions donc également enregistrer ces informations sur
‫la console, mais je pense qu'il est bien plus utile
‫d'avoir ces informations directement dans le facteur, dans ce cas.
‫Ainsi, nous savons déjà faire la distinction entre
‫l'environnement de développement et l'environnement de production.
‫Et donc, faisons-le.
‫Donc
‫si processus. env. node_env est
‫égal au développement alors nous voulons
‫envoyer un type d'erreur et
‫si nous sommes
‫en production, alors nous voulons envoyer une erreur plus simple.
‫Bien.
‫Donc égal à la production.
‫Très bien, prenons celui-ci, donc encore une fois,
‫lors du développement écrit,
‫nous voulons obtenir toutes les informations que nous pouvons.
‫C'est donc aussi imprimer ou répondre avec la pile d'erreurs ici.
‫Alors errez. pile, puis affichons
‫également l'intégralité de l'erreur.
‫Disons une erreur et réglez-le correctement.
‫Ensuite, d'un
‫autre côté, copions à nouveau ceci.
‫Lorsque nous sommes en production, nous ne voulons pas de la pile
‫et nous ne voulons pas non plus de l'erreur complète.
‫Donc vraiment juste le statut et le message.
‫Cela semble un peu
‫compliqué, alors exportons-les dans leurs propres fonctions
‫et aussi parce que nous allons en fait
‫ajouter beaucoup plus de code ici, dans cette branche else.
‫C'est un peu plus propre de les avoir dans
‫leurs propres fonctions distinctes.
‫Supposons donc
‫que const envoie une erreur pour
‫dev et cette fonction devrait alors recevoir l'erreur,
‫et nous devons également transmettre le sujet de la réponse.
‫C'est parce que c'est ainsi que nous pouvons
‫envoyer la réponse, n'est-ce pas ?
‫Nous avons donc besoin du sujet de la réponse pour pouvoir exécuter
‫ce code.
‫Ici, nous allons juste appeler
‫send error dev
‫avec
‫l'erreur et la réponse.
‫Ensuite, ici,
‫nous
‫allons envoyer la production d'erreurs, les
‫mêmes arguments.
‫Et puis ici, pareil.
‫C'était donc facile, passons maintenant au niveau supérieur et
‫parlons à nouveau des erreurs opérationnelles.
‫Pour cela, permettez-moi d'ouvrir la classe d'erreur d'application que
‫nous avons créée, et rappelons-nous que nous
‫marquons toutes les
‫erreurs que nous créons, en utilisant AppError est opérationnel défini sur true.
‫Donc, toutes les erreurs que nous
‫créons nous-mêmes seront essentiellement des erreurs opérationnelles.
‫En fait, ce ne sont que ces erreurs opérationnelles
‫pour lesquelles nous voulons envoyer le message
‫d'erreur au client.
‫Au moins en production.
‫Ainsi, lorsque nous avons, par contre, une erreur de programmation
‫ou une autre erreur inconnue provenant,
‫par exemple, d'un package tiers, nous ne
‫voulons pas envoyer de message d'erreur à ce sujet
‫au client en production.
‫Et donc ça ne sert à rien.
‫C'est une propriété opérationnelle ici dans notre contrôleur d'erreur.
‫Rappelez-vous comment j'ai déjà parlé de le faire
‫au moment où nous avons créé cette classe, n'est-ce pas ?
‫Venons-en maintenant ici pour envoyer la production d'erreurs et
‫faire ce test.
‫Si erreur. isOperational uniquement
‫dans ce cas, nous voulons réellement envoyer cette erreur ici.
‫Dans tous
‫les autres cas, nous
‫allons simplement envoyer un message d'erreur très générique au client.
‫Alors disons, res. status et nous
‫allons simplement envoyer un code 500 générique,
‫puis json.
‫Le statut sera erreur.
‫Ensuite, envoyons simplement un message générique, disant que quelque
‫chose s'est
‫très mal passé.
‫Donc, faire quelque chose comme ça est une procédure très standard.
‫Permettez-moi de commenter une partie du code ici.
‫Il s'agit donc d'une erreur opérationnelle à laquelle nous faisons confiance.
‫Ici, nous voulons envoyer un message au client.
‫Mais dans ce
‫cas ici, nous avons une erreur
‫inconnue, et nous ne voulons donc pas divulguer les détails au client.
‫Nous allons donc simplement envoyer ce message au client,
‫et aussi pour nous-mêmes.
‫Pour nous, développeurs, nous voulons savoir
‫que ce genre d'erreur étrange, inattendue et inconnue s'est
‫produite et nous allons en fait l'enregistrer sur la console.
‫Nous allons d'abord
‫enregistrer l'erreur, puis envoyer un message générique.
‫Disons simplement, console. erreur, c'est donc un peu
‫comme console. log, mais
‫c'est vraiment spécifique aux erreurs et je
‫pense que la sortie sera alors un peu différente.
‫Donc erreur, ajoutons quelques emoji ici pour le rendre
‫visible dans
‫nos journaux, puis enregistrons également l'erreur.
‫Maintenant, il existe de vraies bibliothèques de journalisation sur mpm, que
‫nous pourrions utiliser ici
‫au lieu d'avoir simplement cette simple console. erreur, mais le simple
‫fait de consigner l'erreur sur la console la
‫rendra visible dans les journaux
‫de la plate-forme d'hébergement que vous utilisez.
‫Je pense que pour l'instant, dans ce genre d'application simple,
‫cela suffit.
‫Par exemple, nous allons utiliser
‫Heroku d'ici la fin du cours pour déployer notre application.
‫Ensuite, lorsqu'une erreur comme celle-ci
‫se produit, elle sera enregistrée dans la console.
‫Dans la plateforme Heroku, nous avons alors accès à ces logs.
‫Nous pouvons continuer à consulter ces journaux, puis nous
‫y trouverons ces erreurs inattendues afin de
‫pouvoir ensuite les corriger.
‫À l'heure actuelle, nous construisons déjà une sorte
‫de mécanisme de gestion des erreurs
‫sophistiqué et réel ici.
‫Alors récapitulons rapidement ce que nous venons de faire ici.
‫Nous distinguons les erreurs de développement et
‫de production.
‫Lorsque nous sommes en production, nous envoyons l'erreur
‫à l'aide de cette fonction
‫ici, qui enverra ensuite le plus de détails possible
‫au client, afin
‫que nous obtenions vraiment toutes
‫les informations afin de se débarrasser du bug.
‫S'il s'agit d'une erreur
‫de programmation ou d'une erreur opérationnelle,
‫nous voulons toujours vraiment voir tout ce qui se passe.
‫Lorsque nous sommes
‫en production, ce qui est sans doute la
‫partie la plus importante de notre application, nous distinguons
‫alors les erreurs opérationnelles, donc
‫les erreurs que nous connaissons et auxquelles nous
‫avons confiance, et les autres erreurs, qui peuvent être assez inattendues.
‫Si l'erreur est opérationnelle, par exemple l'utilisateur a essayé d'accéder
‫à une route qui n'existe pas, ou a
‫essayé d'entrer des données invalides, toutes
‫ces erreurs sont opérationnelles.
‫Ensuite, nous pouvons envoyer les messages d'erreur appropriés, pour que
‫le client sache ce qui s'est mal passé.
‫D'un autre côté, nous avons ces erreurs inconnues, ou
‫des erreurs inattendues, et dans ce cas,
‫nous disons très simplement que quelque chose s'est mal passé.
‫Ensuite, enregistrez également l'erreur sur notre console, afin que
‫nous sachions qu'elle s'est produite et que nous puissions ensuite la corriger.
‫Maintenant, pour que cela fonctionne, il y
‫a quelque chose de vraiment, vraiment important que
‫nous devons faire.
‫Il y a actuellement des erreurs
‫qui viennent par exemple de MongoDB, que nous ne marquons pas comme opérationnelles.
‫Dans ce cas, ils seraient simplement traités à l'aide
‫de ce message d'erreur générique ici.
‫Par exemple, une erreur de validation.
‫À l'heure actuelle, c'est une erreur qui
‫vient de MongoDB et non de notre propre classe d'erreur d'application.
‫Nous ne créons pas ces erreurs par nous-mêmes.
‫Encore une fois, ils ne sont actuellement pas marqués comme opérationnels,
‫mais nous devons bien sûr les marquer comme opérationnels afin
‫que nous puissions ensuite renvoyer le message
‫d'erreur approprié au client.
‫Dans l'exemple que je viens de mentionner,
‫que les données d'entrée sont invalides.
‫Il y a deux ou trois autres erreurs que nous
‫devons nous-mêmes marquer comme opérationnelles.
‫Nous allons
‫donc le faire ici.
‫Donc, dans ce bloc else,
‫nous le ferons au cours des deux prochaines conférences.