2009-04-15 5 views
2

Est-ce que quelqu'un connaît une liste opensource des messages d'erreur les plus courants?Est-ce que quelqu'un connaît une liste opensource des messages d'erreur les plus courants?

Ma motivation pour cette question, bien que je sois apte à écrire du code, l'anglais n'est pas ma langue maternelle. Et, une telle liste (un peu, comme toutes ces icônes gratuites sur le net) va raccourcir les dernières étapes de mon développement, Et les bons (et amusants) messages d'erreur font partie d'une bonne interface, je pense. Une motivation de plus, je pourrais avoir quelques idées sur les choses que je devrais vérifier et j'ai oublié.

scénarios communs:

  • Aucune autorisation
  • Plus d'info
  • détails manquants
  • de l'utilisateur Missmatch/pass
+0

Je ne suis pas au courant d'une telle liste, mais peut-être que nous pouvons en créer une si cette question est transformée en wiki. J'ai utilisé les messages Info/Erreur d'Apple comme guide sur certains projets. –

+0

Qu'est-ce qui va changer si je transforme ceci en Wiki? (Je pense que les réponses peuvent être affichées en tant que Wiki quel que soit le type de question). –

+0

Si la question est un wiki, toutes les réponses seront wiki, ce qui est mieux adapté au travail collaboratif. Lisez la FAQ pour plus d'informations: http://stackoverflow.com/questions/128434 –

Répondre

0

Je ne connais rien qui ressemble exactement à ce que vous demandez; un référentiel de messages d'erreur génériques. Si vous avez besoin de messages d'erreur pour les erreurs système, vous devez regarder errno.h; chacune de ces erreurs a une brève description (vérifiez, par exemple, le specification for errno.h, ou peut-être le Linux version). Une autre option consisterait à examiner les projets de traduction pour les logiciels open source existants. Par exemple, consultez le Translation Product.pot files ou le Ubuntu translation project; Cela vous donnera beaucoup de messages d'erreur et d'autres chaînes pour choisir des exemples.Un autre avantage est que vous pourriez être en mesure de vérifier les traductions en your native language à utiliser comme une sorte de pierre de Rosette, si vous avez besoin d'éclaircissements sur quelque chose (même si vous semblez parler et écrire l'anglais assez bien pour poster ici, donc je suis pas sûr si vous en avez besoin).

1

Dans mon expérience, il n'y a que deux types de messages d'erreur: celles spécifiques à l'application que vous développez et celles générées par une API dont votre application dépend.

Le premier type que vous aurez presque toujours besoin d'écrire vous-même. Le second type dépend de si vous voulez le montrer à l'utilisateur. Certains sont formulés assez simplement, vous pouvez simplement les transmettre à l'utilisateur mais dans la plupart des cas, les messages d'erreur produits par une API sont destinés aux développeurs et ne feraient que perturber un utilisateur final.

Par exemple la plupart des systèmes d'exploitation ont un message d'erreur "Fichier non trouvé" ou quelque chose de similaire. En supposant que le fichier que vous avez essayé d'ouvrir a été choisi par l'utilisateur, il est logique de transmettre cette erreur du système d'exploitation directement à l'utilisateur. Alors qu'une erreur "Diviser par zéro" n'aiderait pas l'utilisateur à moins que votre application n'effectue des calculs directement entrés par l'utilisateur. Dans la plupart des cas, cette erreur signifierait une erreur de programmation.

Pour les erreurs spécifiques à l'application. Le message d'erreur n'est utile que dans le contexte de l'endroit où il s'est produit. C'est pourquoi vous ne trouverez pas de collection de messages d'erreur génériques. Les messages d'erreur génériques ne donnent généralement pas assez d'informations à l'utilisateur pour savoir comment répondre.

0

Les messages d'erreur génériques ne sont souvent pas très utiles, car ils ne suggèrent pas à l'utilisateur comment résoudre les problèmes, 2) aident le développeur à corriger les bogues. Donc, si vous voulez écrire de bons messages d'erreur, décidez-vous de les écrire pour l'utilisateur, ou pour le développeur, et de les rendre aussi précis que possible.

"Oups, erreur! [Annuler] [OK] "est inutile. "Test d'intégrité des données dans file.c ligne 33 a échoué. En utilisant la version de sauvegarde. S'il vous plaît signaler cette erreur au développeur "est mieux.

Questions connexes