Gestion des erreurs centrée sur le client

Comprendre et gérer les erreurs

Pour gérer efficacement les erreurs, il est essentiel de comprendre les types d'erreurs qui peuvent survenir. Commençons par catégoriser les erreurs que vous pourriez rencontrer.

Types d'erreurs dans un environnement client Web

Erreurs réseau

• Problèmes de connexion : problèmes lors de l'établissement d'une connexion au serveur.
• Délais d'attente : les demandes prennent trop de temps pour recevoir une réponse.
• Erreurs DNS : problèmes de résolution de nom de domaine.
• Erreurs HTTP : erreurs telles que 404 introuvable, 500 erreur de serveur interne, etc.

Erreurs de l'API du serveur

• Réponses invalides : données inattendues ou mal formées du serveur.
• Erreurs d'authentification : problèmes d'authentification ou d'autorisation de l'utilisateur.
• Limitation du débit : restrictions dues au dépassement des limites d'utilisation de l'API.

Erreurs d’environnement du navigateur utilisateur

• Compatibilité des navigateurs : problèmes résultant des différences dans la façon dont les navigateurs gèrent certaines fonctionnalités.
• Erreurs JavaScript : erreurs dans le code JavaScript côté client.
• Erreurs de chargement des ressources : problèmes de chargement de ressources telles que des images, des scripts ou des feuilles de style.

Autres erreurs

• Erreurs côté client : erreurs liées à l'appareil ou au système d'exploitation de l'utilisateur.
• Erreurs UI/UX : problèmes avec l'interface utilisateur ou l'expérience utilisateur, tels que des liens rompus ou une mise en page incorrecte.

Divers types d'erreurs peuvent survenir. Cependant, ces erreurs peuvent généralement être classées en deux catégories :

1. Erreurs attendues : erreurs dont l'occurrence et la nature sont connues à l'avance.
2. Erreurs inattendues : erreurs dont l'occurrence et la nature ne sont pas connues à l'avance.

Classons les erreurs dont nous avons discuté dans ces classifications.

L'erreur peut-elle être anticipée ou non ?

Erreurs attendues

Les erreurs reçues des API du serveur avec des codes d'état clairs peuvent être considérées comme des Erreurs attendues car elles peuvent être anticipées et traitées à l'avance.

Par exemple, des erreurs telles qu'un accès non autorisé (401) ou un accès interdit (403) peuvent être traitées de manière appropriée en fonction de la situation. Il est également courant de définir des codes d'erreur plus détaillés pour chaque code d'état afin de gérer la logique de l'application en réponse aux erreurs. Celles-ci sont appelées erreurs attendues.

Erreurs inattendues

D'autre part, les erreurs de serveur de l'ordre de 500 sont classées comme Erreurs inattendues car elles sont imprévisibles. Des situations dans lesquelles le serveur ne peut pas répondre pour quelque raison que ce soit peuvent survenir à tout moment. De plus, les erreurs pouvant survenir en raison de l'environnement réseau ou de l'environnement du navigateur de l'utilisateur sont difficiles à prédire et sont donc classées comme erreurs inattendues.

Utilisateur et erreur

Les erreurs peuvent également être classées en fonction de l'interaction avec l'utilisateur, plutôt que simplement de l'environnement. Une façon de catégoriser les erreurs consiste à déterminer si l’utilisateur peut faire quelque chose pour remédier à l’erreur. Voici les critères de ce classement :

1. Erreurs que l'utilisateur peut comprendre et résoudre (Erreurs qui aident l'utilisateur à continuer à utiliser l'application).
2. Erreurs que l'utilisateur ne peut pas résoudre (Erreurs qui n'apportent aucune aide à l'utilisateur).

Erreurs résolubles

Par exemple, les erreurs d'authentification ou d'autorisation entrent dans cette catégorie. Un utilisateur qui n'est pas connecté peut rencontrer une erreur d'état 401. Dans ce cas, vous pouvez fournir un écran de connexion ou afficher un message indiquant qu'une connexion est requise.

Si un utilisateur n'est pas autorisé à accéder à un écran spécifique, vous pouvez le guider pour demander l'accès à un administrateur.

Aucun développeur de produits n'apprécie l'abandon des utilisateurs. Il est essentiel de guider les utilisateurs qui rencontrent des erreurs pour les aider à surmonter la situation. Par exemple, fournir un bouton d'actualisation pour les erreurs réseau temporaires ou un bouton pour revenir à l'écran précédent lors de l'accès à une page inexistante.

Erreurs insolubles

Cependant, il existe des cas où informer l'utilisateur de la situation d'erreur n'aide pas du tout. Par exemple, si le code inclut des composants qui ne fonctionnent pas sur des appareils ou des navigateurs peu performants, l’utilisateur ne peut rien y faire. (Peut-être un message suggérant l'utilisation d'un autre navigateur ?)

Les deux cas, 1 et 2, impliquent de fournir un message. La différence est que le cas 1 inclut une action ou des conseils qui invitent l'utilisateur à prendre des mesures.

L'erreur rencontrée est-elle quelque chose que l'utilisateur peut résoudre lui-même ou non ?

Comment gérer les erreurs

Alors, comment devrions-nous gérer les erreurs qui se produisent ? Quel type d’interface l’application doit-elle fournir à l’utilisateur lorsqu’une erreur se produit ? Explorons comment traiter différents types d'erreurs en fonction de leurs caractéristiques.

Erreurs imprévisibles mais résolubles

Un exemple typique est une erreur réseau. Celles-ci peuvent survenir à tout moment en fonction de l'environnement réseau de l'utilisateur. La solution la plus simple consiste à informer l'utilisateur qu'il s'agit d'une « erreur temporaire » et à lui fournir des conseils pour réessayer l'action précédente.

Plage d'erreur

Pour ces erreurs, il est crucial de s’assurer que l’application dans son ensemble n’est pas affectée. Par exemple, si une application appelle 10 API sur un écran, l'échec d'une API ne devrait pas déclencher de message d'erreur dans l'ensemble de l'application et nécessiter une nouvelle tentative de tous les appels.

Concentrez-vous plutôt sur la récupération uniquement de la zone qui a échoué.

Erreurs imprévisibles et insolubles

Ce sont des erreurs difficiles à anticiper et qui n’ont pas de solution simple. De telles erreurs doivent être minimisées pendant le développement et il doit y avoir un plan pour les gérer lorsqu'elles se produisent. Étant donné que les utilisateurs ne peuvent pas résoudre ces erreurs eux-mêmes, il peut être nécessaire de fournir un moyen simple de contacter le support client.

Surveillance

Les erreurs indépendantes de la volonté du développeur doivent être surveillées à l'aide d'outils comme Sentry. Ces erreurs doivent être corrigées pour empêcher les utilisateurs de les rencontrer. De plus, assurez-vous qu'il existe un mécanisme permettant aux utilisateurs de revenir à l'application s'ils rencontrent de telles erreurs.

Erreurs prévisibles mais insolubles

Il s'agit d'erreurs connues pour lesquelles aucune résolution n'est disponible pour l'utilisateur. Si les utilisateurs ne peuvent pas les résoudre eux-mêmes, cela indique une opportunité manquée de gestion des erreurs. Si les utilisateurs effectuent intentionnellement des actions anormales, cela pourrait être le signe d'une faille de sécurité.

Erreurs liées à la sécurité

Ces erreurs se produisent en cas d'intention malveillante d'exploiter l'application. Ils proviennent généralement de failles de sécurité et doivent être évités pendant le développement. Il est crucial de répondre aux problèmes de sécurité de base tels que CORS et XSS et de collaborer avec l'équipe de sécurité pour créer une application sécurisée.

Erreurs prévisibles et résolubles

Ces erreurs font généralement partie de la logique métier dont les développeurs sont déjà conscients :

• Erreur 401 non autorisée : nécessite une connexion.
• Erreur 404 introuvable : accès à une mauvaise page.
• Autres erreurs de logique métier : définies par la logique de l'application.

Dans ces cas, fournissez des conseils appropriés au sein de l'application ou créez des pages distinctes pour diriger les utilisateurs.

Importance des conseils

Les utilisateurs doivent clairement comprendre quoi faire après avoir rencontré un message d'erreur. Cela permet de réduire la fréquence des erreurs et d’éviter l’abandon des utilisateurs. Par conséquent, à côté du message d’erreur, il est essentiel d’inclure un appel à l’action.

Par exemple, s'il y a une erreur de validation de champ, concentrez-vous sur le champ où l'erreur s'est produite. Si l'utilisateur a accédé à une page inexistante, fournissez un bouton pour revenir à l'écran précédent.

Conclusion

Nous avons exploré la gestion des erreurs. Gérons efficacement les erreurs en utilisant divers outils et technologies tels que les outils de surveillance des erreurs et ErrorBoundary de React, qui peuvent détecter les erreurs dans une portée limitée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!