-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better exceptions #803
Better exceptions #803
Conversation
33a9688
to
6e6ba32
Compare
71edc3e
to
331fb03
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, love the distinction between fatal/ info/warning etc
6c1da71
to
2402969
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice
A few comments:
- I think removing one log for RNE et TVA is a great idea; We have to be careful though we must not make frontend network error silent
- I think that changing
safe
signature will create bugs and unintended behaviours
02ef5b3
to
681b9ba
Compare
- refactor logging of core errors - improve error handling on client - Remove dual logging of TVA error - Name Inpi Error - fix error when calling localstorage Nous utilisons [Sentry](https://errors.data.gouv) pour remonter les erreurs du site. Voici les bonnes pratiques à suivre pour remonter une erreur : 1. **Utiliser le bon niveau d'erreur** - `logFatalErrorInSentry` : une erreur qui empêche tout ou une partie du site de fonctionner. Une page d'erreur est affichée à l'utilisateur. - `logErrorInSentry` : une fonctionnalité importante du site ne fonctionne pas. - `logWarningInSentry` : une fonctionnalité mineure du site ne fonctionne pas. Un comportement imprévu est arrivé. Non bloquant pour l'utilisateur. - `logInfoInSentry` : information sur le comportement du site 2. **Logguer des erreurs et non des string**. Cela permet d'avoir les stacktrace complètes et uniformise l'affichage dans sentry. Pour cela vous pouvez vous aider de la classe `Exception` ```typescript logErrorInSentry(new Exception({ name: 'RedisClientFailException' }); ``` 3. **Remonter des erreurs métiers** : l'erreur doit informer sur ce qui n'a pas fonctionné du point de vue de l'utilisateur. Vous pouvez utiliser le paramètre `cause` pour logguer l'erreur technique à l'origine de l'erreur métier. Vous pouvez également ajouter des informations contextuelles sur l'erreur via le paramètre `context`. ```typescript try { // ... } catch (e) { logErrorInSentry( new Exception({ name: 'AgentConnectionFailedException', message: 'Error during authentication', cause: e, context: { siren, siret, details: agentId, }, }) ); } ``` 4. **Utiliser des classes d'erreur spécialisée**. - `Exception` : erreur métier - `InternalError` : bug interne du code qui n'est **jamais** supposé arriver - `FetchRessourceException` : erreur lors d'un appel à une API externe Vous pouvez en créer d'autres en étendant la classe `Exception`.
681b9ba
to
e2f3b43
Compare
e2f3b43
to
f432664
Compare
message: 'Formatting error in view', | ||
cause: e, | ||
context: { | ||
details: argsAsString, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if toString() fail, Sentry might not be able to serialize it either
Dernière refacto sur la remontée d'erreur pour nettoyer Sentry, et repartir sur de bonnes bases.
Best practices à respecter
fatal
: une erreur qui empêche tout ou une partie du site de fonctionner. Une page d'erreur est affichée à l'utilisateur.logErrorInSentry
: une fonctionnalité importante du site ne fonctionne pas.logWarningInSentry
: une fonctionnalité mineure du site ne fonctionne pas. Un comportement imprévu est arrivé. Non bloquant pour l'utilisateur.logInfoInSentry
: information sur le comportement du siteException
cause
pour logguer l'erreur technique à l'origine de l'erreur métier. Vous pouvez également ajouter des informations contextuelles sur l'erreur via le paramètrecontext
.Exception
: erreur métierInternalError
: bug interne du code qui n'est jamais supposé arriverFetchRessourceException
: erreur lors d'un appel à une API externeVous pouvez en créer d'autres en étendant la classe
Exception
.