À quel point les messages d'erreur devraient-ils être détaillés?

Question

Je me demandais quel était le consensus général sur les messages d'erreur. À quel point devraient-ils être détaillés?

J'ai travaillé sur des projets comportant un message d'erreur différent lors de la saisie d'un nombre trop grand, trop petit, avec une décimale, une chaîne, etc. C'était très agréable pour l'utilisateur, car il savait exactement où les choses se sont mal passées, mais le code de traitement des erreurs a commencé à rivaliser avec la logique commerciale réelle et a commencé à développer certains de ses propres bogues.

De l'autre côté, j'ai travaillé sur un projet dans lequel des erreurs très génériques telles que

seraient générées.

  

ÉCHEC COMPILER RAISON 3

Ce qui est inutile de dire était presque entièrement inutile car la raison 3 s'est avérée vouloir dire une erreur de lien.

Alors, où est le juste milieu? Comment savoir si j'ai ajouté des messages d'erreur suffisamment descriptifs? Comment savoir si l'utilisateur sera capable de comprendre où il s'est trompé?

Answer 1

Il existe deux types de public cible pour un message d'erreur: l'utilisateur et le développeur.

Le message devrait généralement cibler l'utilisateur.

o quelle est la cause du problème.
 o pourquoi le programme ne peut pas contourner le problème
 o ce que l'utilisateur peut faire pour résoudre le problème.
 o comment signaler le problème.

Si le problème doit être signalé, le rapport doit inclure autant d'informations de contexte de programme que possible.

o nom du module
 o nom de la fonction
 o numéro de ligne
 o variables d'intérêt dans le domaine général du problème
 o peut-être même un dépotoir.

Ciblez le bon public.

Answer 2

Vous devez communiquer ce qui s'est passé et quelles sont les options de l'utilisateur, le plus rapidement possible. Plus le message d'erreur est long, moins l'utilisateur est susceptible de le lire. De même, les messages d'erreur courts sont cryptés et inutiles. Il y a un bon compromis en termes de longueur, et il est différent pour chaque situation.

Trop court:

  

Entrée non valide.

Trop long:

  

Veuillez saisir une adresse IP correctement formatée, telle que 192.168.0.1. Une adresse IP est un numéro utilisé pour identifier votre ordinateur sur un réseau.

Juste comme il faut:

  

Veuillez entrer une adresse IP valide.

En ce qui concerne le gonflement du code, si un peu de code supplémentaire empêche un utilisateur d’appeler le support ou de s’énerver, c’est un bon investissement.

Answer 3

Il existe deux types de messages d'erreur: ceux qui seront vus par l'utilisateur et ceux qui seront vus par le programmeur.

"Comment savoir si l'utilisateur parviendra à comprendre où il s'est trompé?" Je suppose que ces messages ne seront vus que par l'utilisateur, et pas très techniques, et que COMPILE FAILED REASON 3 n'est pas un message d'erreur typique de l'utilisateur final. C’est quelque chose que le programmeur verra (l’utilisateur ne compile généralement pas les choses).

Donc, si c'est l'utilisateur qui le verra:

1. Fournissez un court message "Ceci est un message d'erreur" ("Ops! Quelque chose ne va pas!", etc.)
2. Fournissez une petite description générique de l'erreur ("Le site auquel vous essayez de vous connecter semble être indisponible" / "Vous ne semblez pas disposer des autorisations suffisantes pour exécuter la tâche XYZ" / etc.)
3. Ajouter un " Détails > > " bouton, au cas où votre utilisateur comprendrait bien les ordinateurs, y compris des informations détaillées (trace de pile d’exceptions, code d’erreur, etc.)

Enfin, fournissez des commandes simples et compréhensibles à l'utilisateur ("Réessayer", "Annuler", etc.)

.

Answer 4

La vraie question à propos des messages d'erreur est de savoir s'ils devraient même être affichés. Un grand nombre de messages d'erreur sont présentés à un utilisateur, mais il n'y a AUCUN MOYEN pour eux de les corriger.

Dans la mesure où il existe un moyen de corriger l'erreur, donnez suffisamment d'informations à l'utilisateur pour lui permettre de les corriger lui-même. S'ils ne sont pas en mesure de le corriger par eux-mêmes, y a-t-il une raison de leur dire la raison technique de l'accident? Non, il suffit de le consigner dans un fichier pour le dépannage ultérieur.

Answer 5

Aussi détaillés que nécessaire;)

Je sais que cela ressemble à une réponse intelligente, mais cela dépend en grande partie de votre public cible et du type d'erreur. Pour les erreurs causées par une entrée d'utilisateur non valide, vous pouvez leur montrer ce qui constitue une entrée valide. Pour les erreurs que l'utilisateur ne peut pas contrôler, un générique "nous y travaillons" type de message pourrait faire.

Je suis également d’accord avec les commentaires de Jon B. B concernant la longueur.

Answer 6

Les messages d'erreur doivent être détaillés mais clairs. Ceci peut être réalisé en combinant des messages d'erreur de plusieurs niveaux:

Failed to save the image
Permission denied: /foo.jpg

Ici nous avons deux niveaux. Il peut y avoir plus. Nous décrivons d'abord la situation dans son ensemble, puis les détails. L'ordre est tel que nous avons d'abord la partie comprise par la plupart, puis la partie moins comprise par les gens, mais les deux peuvent toujours être visibles.

De plus, il pourrait y avoir une suggestion de solution.

Answer 7

Je préférerais avoir plus de détails, mais je pense que vous avez répondu à votre propre question. Pour éviter toute surcharge de code, fournissez des informations utiles dans le code / message d'erreur, mais vous pouvez donner plus de détails dans la documentation, éventuellement avec des fichiers d'aide ou des FAQ.

avoir trop peu d'informations est pire à mon avis.

Si vous utilisez une langue avec une introspection riche ou d’autres capacités, un journal avec la ligne ayant échoué à une vérification serait utile. L'utilisateur peut ensuite transmettre au support technique ou obtenir des informations détaillées. Il ne s'agit pas d'un code supplémentaire volumineux, mais de l'utilisation de votre propre code pour fournir des informations.