‫Enseignant : Dans cette
‫vidéo, créons maintenant une classe d'erreurs meilleure et plus
‫utile, et effectuons également une refactorisation.
‫Et en commençant par cette classe
‫d'erreur, créons un nouveau fichier dans notre dossier Utilitaires.
‫Alors, nouveau fichier, et je vais l'appeler
‫AppError parce que ça va être le nom de la classe, d'accord ?
‫Donc, classe AppError, et nous voulons en fait que tous nos
‫objets AppError héritent ensuite de l'erreur intégrée,
‫et étendons donc en fait la classe d'erreur intégrée.
‫Donc, nous avons utilisé l'extension Error, d'accord ?
‫Donc, nous l'avons déjà fait quelque part dans ce cours,
‫et encore une fois, ce ne sont que des cours ES6, d'accord ?
‫Dans ce cas, l'héritage
‫de classe, où une classe hérite de l'autre, d'accord ?
‫Ensuite, comme toujours, notre constructeur, et ce
‫que nous allons passer dans un
‫nouvel objet créé à partir de la
‫classe AppError, va être le message et le statusCode, donc juste
‫ces deux.
‫Bon, alors, rappelez-vous que la méthode constructeur est appelée chaque
‫fois que nous créons un nouvel objet à partir de cette classe.
‫Maintenant, comme d'habitude, lorsque nous étendons
‫une classe parent, nous appelons super afin d'appeler le
‫constructeur parent, d'accord, et nous
‫le faisons avec message car le message est
‫en fait le seul paramètre que l'erreur intégrée accepte.
‫D'accord, donc c'est fondamentalement que vous appelez une
‫erreur, d'accord, et puis voici les
‫choses habituelles, nous
‫définissons le statusCode sur statusCode, d'accord, et maintenant nous
‫voulons également définir le statut lui-même.
‫Donc, rappelez-vous que le statut peut être soit un échec, soit une
‫erreur, et nous pourrions le transmettre à
‫l'objet, mais ce n'est pas
‫non plus vraiment nécessaire, car le statut dépend du statusCode.
‫Ainsi, lorsque le statusCode est un 400,
‫alors le statut sera
‫fail, et s'il s'agit d'un 500, alors ce sera une erreur,
‫n'est-ce pas, et cela teste simplement si
‫le statusCode commence par un quatre.
‫Donc, en JavaScript, il existe une méthode startWith que nous pouvons appeler
‫sur des chaînes, et je
‫pense donc que c'est la façon la plus simple
‫de faire ce test, et c'est donc essentiellement convertir le statusCode
‫en chaîne, et pour cela j'utilise simplement un chaîne de
‫modèle avec le code là-dedans, donc ceci, ou
‫en fait, nous pouvons simplement utiliser statusCode.
‫Donc, statusCode,
‫puis startsWith, alors ici nous avons aussi
‫besoin d'une chaîne, et donc si le statusCode en tant
‫que chaîne commence par un quatre, eh bien, alors nous avons un échec.
‫Et donc ici, utilisons le ternaire, d'accord, et
‫donc c'est un échec quand il commence
‫par un quatre, et sinon c'est une erreur, d'accord ?
‫Donc, très simple, et cela nous évite
‫déjà d'avoir à transmettre manuellement soit un échec, soit une erreur.
‫Très bien, maintenant, toutes les erreurs
‫que nous allons créer
‫en utilisant cette classe seront toutes des erreurs opérationnelles.
‫Ainsi, des erreurs que nous
‫pouvons prédire se produiront à un moment
‫donné dans le futur, comme par exemple
‫un utilisateur créant une visite sans les champs requis, n'est-ce pas ?
‫C'est donc une erreur opérationnelle, d'accord, et encore une
‫fois, à partir de maintenant, nous
‫utiliserons toujours cette classe AppError ici que
‫nous créons en ce moment
‫afin de créer toutes les erreurs dans notre application.
‫Et donc ces erreurs seront des erreurs opérationnelles, et donc ce
‫que je vais faire maintenant
‫est de créer également un fichier . est la propriété opérationnelle ici.
‫Donc ça. est opérationnel
‫et définissez-le sur true.
‫Ainsi, toutes nos erreurs auront
‫cette propriété définie sur true, et je
‫le fais pour que
‫nous puissions ensuite tester cette propriété et renvoyer
‫des messages d'erreur au client uniquement
‫pour ces erreurs opérationnelles que nous avons
‫créées à l'aide de cette classe.
‫Et cela est utile car d'autres
‫erreurs inattendues et folles peuvent se produire dans
‫notre application, par exemple une erreur de programmation
‫ou un bogue dans l'un des packages
‫dont nous avons besoin dans notre application,
‫et ces erreurs
‫n'auront bien sûr pas ceci. est une propriété opérationnelle
‫sur eux, d'accord, et cela peut sembler
‫un peu déroutant à ce stade,
‫mais ne vous inquiétez pas, cela
‫aura beaucoup de sens lorsque nous
‫implémenterons ensuite cette partie que je viens de mentionner.
‫Alors, à tester pour ça. est la propriété opérationnelle ici.
‫Très bien, et maintenant juste une dernière
‫étape est que nous devons également capturer la trace de la pile.
‫Maintenant, qu'est-ce que j'entends par trace de pile ?
‫Et donc, permettez-moi de vous montrer cela,
‫donc, de vous montrer ce qu'est la trace de la
‫pile, et je vais donc l'enregistrer ici sur la console.
‫Console. journal et erreur. stackTrace,
‫donc chaque erreur obtient cette trace de pile, et
‫en fait c'est juste une pile, d'accord.
‫Alors errez. stack nous montrera
‫essentiellement où l'erreur s'est produite.
‫Alors laissez-moi exécuter ceci
‫ici maintenant, et alors jetons un coup
‫d'œil à cela, et cela
‫nous donne ici l'erreur et ensuite aussi où c'est arrivé, d'accord ?
‫Donc, dans ce cas ici,
‫bien sûr, ajoutez app. js à la ligne 32.
‫Alors, juste ici.
‫C'est donc là que nous
‫avons créé cette erreur, et elle se
‫trouve donc maintenant dans notre trace de pile, et elle nous
‫montre également l'intégralité de la pile d'appels ici, qui à la fin est à l'origine de cette erreur, d'accord ?
‫Donc, nous voulons en quelque
‫sorte préserver cela et en même temps ne pas ajouter cette méthode
‫ici, ou cette classe, à cette piste de pile, d'accord ?
‫Et encore une fois, cela semble un
‫peu déroutant, je sais, mais dans
‫ce cas, ce n'est pas vraiment important, tout ce
‫qui compte, c'est que nous ajoutions simplement cette ligne de code
‫ici, qui est Error. capturestackTrace, donc exactement
‫ce que vous obtenez ici,
‫et nous devons d'abord spécifier l'objet actuel,
‫qui est celui-ci, puis la classe AppError elle-même, qui
‫sera celle-ci. constructeur.
‫D'accord, et ainsi, lorsqu'un nouvel objet est créé et
‫qu'une fonction constructeur est appelée, cet appel de fonction n'apparaîtra
‫pas dans la trace de
‫la pile et ne la polluera pas.
‫Très
‫bien, plaçons-le ici, et
‫oui, c'est donc notre classe AppError, et
‫donc exportons-la maintenant à partir d'ici.
‫Alors, module. exports est bien sûr l'AppError.
‫Super, juste une question que vous pourriez avoir est « Pourquoi
‫n'ai-je pas défini cela ? message égal au message? ' Eh bien,
‫c'est juste parce qu'ici j'ai appelé la classe
‫parent, à droite, et la classe parent
‫est error, et tout ce que nous lui transmettons
‫sera la propriété du message.
‫Alors comme je te l'ai dit avant.
‫Et donc, fondamentalement, ici, en effectuant cet appel parent, nous avons
‫déjà défini la propriété message sur
‫notre message entrant.
‫Très bien, sauvegardez-le, et maintenant nous pouvons le fermer, nous
‫n'en avons plus
‫besoin, et ici nous allons juste l'importer ici.
‫Const
‫AppError, require, puis c'est dans utils,
‫donc Utilities, et appError, d'accord, et
‫maintenant allons-y et utilisons-le.
‫Commentez ce morceau de code, et
‫supprimez en fait celui que nous avions auparavant,
‫et cela va
‫maintenant créer l'erreur ici à l'intérieur du suivant.
‫Donc, nouvelle AppError, puis le
‫message, qui est
‫celui-ci, et le
‫code d'état.
‫Bon, et l'échec, rappelez-vous, sera
‫alors automatiquement compris, et donc supprimons tout cela, sauvegardons-le
‫ici, et
‫une fois de plus, testez ce mauvais itinéraire, et en
‫effet nous obtenons toujours la même erreur,
‫et nous obtenons également exactement la même trace de pile.
‫D'accord, et enfin je veux
‫aussi exporter ce middleware ici, d'accord ?
‫Donc, fondamentalement, ce gestionnaire parce
‫que dans le reste de la
‫section, nous allons créer quelques
‫fonctions différentes pour gérer différents types d'erreurs, et donc je
‫veux que toutes ces
‫fonctions soient toutes dans le même fichier, d'accord ?
‫Et nous pouvons dire que toutes ces fonctions
‫que je viens de mentionner sont des gestionnaires, d'accord, et
‫donc des gestionnaires, nous les appelons également des
‫contrôleurs dans le contexte de l'architecture MVC, et
‫créons donc maintenant un
‫fichier de contrôleur d'erreur dans notre dossier de contrôleur.
‫D'accord, et cela peut sembler un peu bizarre parce que nous n'avons en
‫fait pas de ressource d'erreur d'accord, et donc probablement certaines
‫personnes ne seront pas d'accord avec moi pour dire
‫que c'est le bon endroit, mais
‫personnellement j'aime le faire comme ça parce qu'à
‫en fin de
‫compte, ces fonctions, elles sont un peu
‫comme pour contrôler nos erreurs, d'accord, et donc
‫pour moi au moins, il est
‫logique d'appeler simplement cette fonction ici le contrôleur d'erreur, et ici je
‫voulais coller cette fonction middleware , mais je suppose que je
‫ne l'ai pas copié, alors faisons-le à nouveau.
‫Très bien, et en fait, je vais exporter celui-ci ici
‫en tant que module. exporte parce que
‫les autres fonctions de
‫gestion que nous allons créer plus
‫tard, je ne les exporterai pas à partir d'ici.
‫Donc, ils vont juste être en quelque sorte des aides.
‫Alors, module. exportations est égal à cette fonction, d'accord ?
‫Débarrassons-nous réellement de cette console. connectez-vous ici, sauvegardez-le,
‫et maintenant de retour dans notre application,
‫nous devons bien sûr maintenant brancher
‫cette fonction middleware ici.
‫Alors, allons de l'avant et importons-le et
‫je peux l'appeler comme je
‫veux,
‫et laissez-moi donc l'appeler
‫le globalErrorHandler avec un H
‫majuscule, et je
‫vais avoir besoin de contrôleurs et d'errorController.
‫Remettez-le ici, et maintenant pour le test final
‫après cette refactorisation.
‫Voyons voir, et encore une
‫fois, tout fonctionne très bien, d'accord ?
‫Alors, parfait, c'était le but de cette vidéo, à bientôt
‫dans la suivante.