> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Pratiques exemplaires de gestion des erreurs du SDK

> Pratiques exemplaires pour détecter, examiner et gérer les erreurs d'API PlayFab retournées par les SDK Admin, Server et Client dans différents langages.

Ce tutoriel montre comment accéder aux erreurs d'API, les reconnaître et les gérer à l'aide du SDK PlayFab.

Les pratiques décrites ici s'appliquent aussi bien aux SDK Admin, Server et Client, mais les modèles dépendent *fortement* du langage que vous choisissez.

En résumé, le modèle que vous choisissez sera valable pour n'importe quel SDK (Admin/Server/Client), mais les détails d'implémentation seront propres à *votre* langage de programmation et à votre environnement.

## Interception de l'erreur et accès à celle-ci

Les SDK PlayFab signalent généralement les erreurs en retournant un objet d'erreur. L'extrait suivant montre comment détecter l'erreur et y accéder.

```csharp theme={null}
PlayFabClientAPI.LoginWithEmailAddress(new LoginWithEmailAddressRequest() {
    Email = "doesnotexist@mail.com",
    Password = "nevercorrect",
}, result => {
    // success
}, error => {
    // 'error' object is our point of access to error data
});
```

En général, si un objet d'erreur est défini (non null), cela indique qu'une erreur s'est produite. Nous pouvons alors examiner l'erreur plus en détail.

## Examen de l'erreur

La façon la plus courante d'examiner une erreur consiste à la reconnaître grâce à son code. Comme décrit dans [Codes d'erreur globaux des méthodes d'API](/fr-CA/services/playfab/api-references/global-api-method-error-codes), chaque erreur générée contient des codes d'erreur lisibles et numériques.

<Note>
  Le code suffit *à lui seul* pour reconnaître l'erreur et la traiter en conséquence.
</Note>

Prenons comme exemple la méthode d'API [LoginWithEmailAddress](xref:titleid.playfabapi.com.client.authentication.loginwithemailaddress). Comme l'indique la [documentation](xref:titleid.playfabapi.com.client.authentication.loginwithemailaddress) de cette méthode, les erreurs internes suivantes peuvent être levées lors de l'exécution :

* `InvalidTitleId 1004`
* `AccountNotFound 1001`
* `InvalidEmailOrPassword 1142`
* `RequestViewConstraintParamsNotAllowed 1303`

La méthode suivante montre comment examiner et reconnaître une telle erreur.

```csharp theme={null}
PlayFabClientAPI.LoginWithEmailAddress(new LoginWithEmailAddressRequest() {
    Email = "doesnotexist@mail.com",
    Password = "nevercorrect",
}, result => {
    // success
}, error => {
    // General purpose logging: GenerateErrorReport gives a bunch of information about the error
    Debug.Log(error.GenerateErrorReport());

    // Recognize and handle the error
    switch (error.Error) {
        case PlayFabErrorCode.InvalidTitleId:
            // Handle invalid title id error
            break;
        case PlayFabErrorCode.AccountNotFound:
            // Handle account not found error
            break;
        case PlayFabErrorCode.InvalidEmailOrPassword:
            // Handle invalid email or password error
            break;
        case PlayFabErrorCode.RequestViewConstraintParamsNotAllowed:
            // Handle not allowed view params error
            break;
        default:
            // Handle unexpected error
            break;
    }
});
```

## Gestion de l'erreur

Une fois l'erreur identifiée, la stratégie de gestion/récupération dépend du type et de la nature de l'erreur. Les erreurs telles que les *arguments non valides* n'aboutiront jamais en cas de nouvelle tentative. La requête doit être corrigée pour que cet appel d'API réussisse.

Il existe un sous-ensemble d'erreurs pour lesquelles une stratégie de nouvelle tentative peut être appliquée. Les types d'erreurs *pouvant faire l'objet d'une nouvelle tentative* sont décrits dans [Codes d'erreur globaux des méthodes d'API](/fr-CA/services/playfab/api-references/global-api-method-error-codes).

Veillez à respecter les exigences suivantes lorsque vous appliquez une stratégie de nouvelle tentative :

* À chaque nouvelle tentative, le délai entre les tentatives doit *augmenter* de façon exponentielle. Cela *augmente* vos chances de réussite de l'appel et évite que votre jeu ne submerge le serveur PlayFab (ce qui entraînerait *davantage* d'appels rejetés).

* Vous devez appliquer cette stratégie de nouvelle tentative de façon *sélective*, uniquement pour les codes qui justifient une nouvelle tentative.

Consultez notre tutoriel [Codes d'erreur globaux des méthodes d'API](/fr-CA/services/playfab/api-references/global-api-method-error-codes) pour obtenir la liste des codes pour lesquels une nouvelle tentative est sûre.


## Related topics

- [Utilisation côté client des privilèges utilisateur des services XBOX](/fr-CA/services/xbox-services/fundamentals/identity/privileges/concepts/live-user-privileges-client.md)
- [Gestion des erreurs du SDK C++ Lobby et Matchmaking](/fr-CA/services/playfab/multiplayer/lobby/lobby-and-matchmaking-client-sdk-errors.md)
- [Pratiques exemplaires](/fr-CA/services/xbox-services/develop/best-practices/index.md)
- [Pratiques exemplaires pour appeler les services XBOX](/fr-CA/services/xbox-services/develop/best-practices/live-best-practices-calling-xbl.md)
- [Pratiques exemplaires d'Insights](/fr-CA/services/playfab/data-analytics/legacy/insights/best-practices.md)