Dois-je éviter d'essayer catch dans chaque async / wait sur Node js?

try..catch peut être nécessaire si une fonction est capable de récupérer d'une erreur, de faire un effet secondaire comme la journalisation ou de renvoyer une erreur plus significative.

Si CustomError est plus préférable qu'une erreur que apiCall peut lancer puis try..catch nécessaire, sinon ce n'est pas le cas. Le problème avec foo est qu'il ne gère que les erreurs synchrones. Afin de gérer les promesses rejetées, il devrait être return await apiCall () , c'est un piège connu de async.

Les rejets non interceptés sont indésirables, ils entraînent actuellement UnhandledPromiseRejectionWarning et devraient planter Node dans les versions futures. Il est préférable de gérer une erreur de manière significative au plus haut niveau, donc main doit attraper l'erreur. Cela peut être délégué au gestionnaire d'événements process uncaughtRejection , mais il peut être avantageux pour lui de conserver un niveau supplémentaire de gestion des erreurs qui ne devrait jamais être atteint.

Le résultat que nous voyons est qu'un rejet de promesse non gérée est enregistré dans la console.

Cela ne devrait pas arriver. Un rejet doit être traité par le test. Un point d'échec possible est expliqué ci-dessus, foo peut renvoyer l'erreur d'origine de apiCall au lieu de CustomError au cas où il n'aurait pas été correctement simulé, ceci échouera à l'attente et entraînera un rejet non géré dans catch () . Un autre point d'échec est que le test a une promesse déchaînée car il n'a pas été retourné, le test réussit toujours.

Le test asynchrone qui utilise des promesses doit toujours renvoyer une promesse. Cela peut être amélioré en utilisant async..await . foo est async , il devrait toujours renvoyer une promesse:

it('foo should throw', async () => {
    foo.mockImplementantion(() => { return Promise.reject(new CustomError('error')) });
    await expect(bar()).rejects.toThrow(CustomError);
})

Maintenant, même si foo code> mock échoue ( foo mock n'affectera pas bar s'ils sont définis dans le même module que celui indiqué) et bar rejette avec quelque chose qui n'est pas CustomError , cela sera affirmé.

Non. Vous n'avez pas besoin d'utiliser try / catch dans chaque async / await. Vous n'avez besoin que de le faire au plus haut niveau. Dans ce cas, la fonction principale que vous utilisez déjà.

La météo que vous devriez est une question d'opinion. Les concepteurs du langage go sont suffisamment convaincus à ce sujet qui est devenu la norme dans go pour toujours gérer les erreurs à chaque appel de fonction. Mais ce n'est pas la norme en javascript ou dans la plupart des autres langages.

Rejet de promesse non gérée

Votre rejet de promesse non gérée est déclenché par votre fonction it () car vous ne lui dites pas d'attendre la fin de la promesse.

Je suppose que vous utilisez quelque chose comme mocha pour le test unitaire (d'autres frameworks peuvent fonctionner différemment). Dans mocha, il existe deux façons de gérer les tests asynchrones:

1. Appelez le rappel done - la fonction it () sera toujours appelée avec un rappel done . C'est à vous de savoir si vous voulez l'utiliser ou comme dans votre code posté pour ne pas l'utiliser:

    describe('testing bar', () => {
        it('foo should throw', (done) => {
            foo.mockImplementantion(() => { throw new CustomError('error')});
   
            return bar() // <----------- THIS WOULD ALSO FIX IT
            .then((result) => {
                console.log(result);
             })
            .catch((err) => {
                exepect(err).toBeInstanceOf(CustomError);
            })
        })
    })
   

2. Renvoyez une promesse. Si vous renvoyez une promesse à la fonction it () , mocha sera conscient que votre code est asynchrone et attendra la fin:

    describe('testing bar', () => {
        it('foo should throw', (done) => {
            foo.mockImplementantion(() => { throw new CustomError('error')});
            bar()
            .then((result) => {
                console.log(result);
                done(); // ------------- THIS IS YOUR ACTUAL BUG
             })
            .catch((err) => {
                exepect(err).toBeInstanceOf(CustomError);
                done(); // ------------- THIS IS YOUR ACTUAL BUG
            })
        })
    })
   

En bref, il n'y a rien de mal avec votre code. Mais vous avez un bogue dans votre test unitaire .