Considérez une application GUI C # qui utilise un Si la lecture échoue avec Une des exceptions , quoi est la bonne façon de signaler l'échec à l'utilisateur, de manière conviviale?
Devrais-je inventer mon propre message pour chacune de ces exceptions ou y a-t-il une façon d'obtenir un message Je demande si .Net lui-même est capable de me fournir une chaîne descriptive que je peux présenter (et qui serait cohérente avec d'autres programmes .NET). Je sais que je peux me rouler le mien, mais j'aimerais éviter cela s'il y a une alternative . filtream pour lire un fichier, choisi par l'utilisateur via une boîte de dialogue "Ouvrir le fichier".
Edit
3 Réponses :
Vous pouvez avoir un ensemble d'exceptions utilisateur localisables avec l'une d'entre elles étant indiquer Ma suggestion serait:
Fileduploaderror . Vous pouvez mettre une information générale localisée là-bas. Lancer quelques détails techniques peut être un peu difficile, car il peut être assez difficile d'obtenir le bon équilibre entre les détails techniques et une étape simple qu'un utilisateur doit prendre pour corriger une erreur.
fileduploaderrorexception
Si vous attrapez une exception projetée par l'une des classes de fichier .NET Framework, il est probable que le contenu de la propriété supposant que vous puissiez écrire une méthode Si vous souhaitez inclure des informations supplémentaires pouvant être utiles à une personne d'assistance diagnostiquant le problème, vous pouvez également obtenir la pile Trace comme une chaîne de l'exception. .Message de l'exception sera déjà localisé. La propriété .Message est censée contenir du texte lisible humain localisé. À quel point cela dépend, je suppose, mais cela pourrait contenir quelque chose que vous pouvez intégrer dans un paragraphe plus général et convivial. alertantwithmessage () pour afficher l'erreur à l'utilisateur, cela pourrait être utile:
Les messages d'exception sont par nature techniques et décrivent ce qui s'est mal passé (au niveau de la mise en œuvre), par opposition à la manière de résoudre le problème d'un utilisateur final. D'autre part, l'intention d'un message d'erreur présenté à l'utilisateur est d'expliquer ce qui a échoué et quelles actions à prendre pour remédier au problème. Les messages d'exception et les messages d'erreur d'utilisateur final n'ont pas le même objectif et ne sont pas écrits pour le même public.
Ainsi, pour une expérience utilisateur décente, il est beaucoup préférable de cartographier ces exceptions à des conseils conviviaux localisés sur la manière de contourner le problème. Bien sûr, pour des utilisateurs techniques, il pourrait être agréable d'avoir une fonctionnalité de diagnostic qui pourrait donner des détails de l'exception (auquel cas avoir des messages d'exception en anglais n'a pas d'importance que beaucoup - l'anglais est vraiment la langue technique du monde), ou juste point eux à un journal avec tous les détails. Mais je viens de jeter un message d'exception, même localisé, à un utilisateur final est susceptible de les déferler.
Pour cette raison, je ne pense pas que la localisation des messages d'exception est très utile. Il est vrai que le .NET Framework a localisé des messages d'exception localisés pour les grandes langues, mais je pense que c'est plus parce qu'il y a des développeurs qui utilisent ces langues comme langue de base et ne maîtrisent pas nécessairement une bonne maîtrise de l'anglais. Donc, le public de ces messages d'exception localisés est toujours des développeurs et non des utilisateurs finaux d'un produit logiciel intégré à .NET.
De quel type de demande parle-t-on? Est-ce un site Web, un mobile, un bureau ou peut-être une bibliothèque? Combien de détails êtes-vous prêt à exposer à l'utilisateur?
Une application de bureau C # avec une interface graphique dans WPF. Je suis disposé à exposer suffisamment d'informations pour un utilisateur non technique pour comprendre ce qui ne va pas et ce qu'ils doivent faire.