Skip to content
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

Merged
merged 2 commits into from
Dec 11, 2023
Merged

Better exceptions #803

merged 2 commits into from
Dec 11, 2023

Conversation

johangirod
Copy link
Contributor

@johangirod johangirod commented Nov 27, 2023

Dernière refacto sur la remontée d'erreur pour nettoyer Sentry, et repartir sur de bonnes bases.

Best practices à respecter

  1. Utiliser le bon niveau d'erreur
  • 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 site
  1. 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
  logErrorInSentry(new Exception({ name: 'RedisClientFailException' });
  1. 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.
try {
  // ...
} catch (e) {
  logErrorInSentry(
    new Exception({
      name: 'AgentConnectionFailedException',
      message: 'Error during authentication',
      cause: e,
      context: {
        siren,
        siret,
        details: agentId,
      },
    })
  );
}
  1. 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.

@johangirod johangirod force-pushed the TMP-better-exceptions branch 3 times, most recently from 33a9688 to 6e6ba32 Compare November 27, 2023 15:00
@johangirod johangirod marked this pull request as ready for review November 27, 2023 15:01
@XavierJp XavierJp self-requested a review November 28, 2023 08:57
@johangirod johangirod force-pushed the TMP-better-exceptions branch 2 times, most recently from 71edc3e to 331fb03 Compare November 28, 2023 17:21
Copy link
Contributor

@XavierJp XavierJp left a 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

frontend/src/fetch-tva.js Outdated Show resolved Hide resolved
models/association.ts Outdated Show resolved Hide resolved
@johangirod johangirod force-pushed the TMP-better-exceptions branch 12 times, most recently from 6c1da71 to 2402969 Compare December 7, 2023 09:41
Copy link
Contributor

@XavierJp XavierJp left a 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

README.md Show resolved Hide resolved
components/table/simple.tsx Show resolved Hide resolved
hooks/fetch/immatriculation-rne.ts Outdated Show resolved Hide resolved
utils/helpers/formatting/formatting.ts Outdated Show resolved Hide resolved
utils/helpers/formatting/formatting.ts Outdated Show resolved Hide resolved
@johangirod johangirod force-pushed the TMP-better-exceptions branch 5 times, most recently from 02ef5b3 to 681b9ba Compare December 11, 2023 12:29
- 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`.
Comment on lines +24 to +28
message: 'Formatting error in view',
cause: e,
context: {
details: argsAsString,
},
Copy link
Contributor

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

@XavierJp XavierJp merged commit 5f57917 into main Dec 11, 2023
6 checks passed
@XavierJp XavierJp deleted the TMP-better-exceptions branch December 11, 2023 17:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants