Terminez-vous vos messages d'exception par un point ?

Question

J'ai vu des messages d'exception avec et sans point. Et je peux penser à quelques raisons pour lesquelles les deux pourraient être bons.

• L'absence de point vous donnerait la liberté d'ajouter le point ou de l'omettre si vous le souhaitez. Cela pourrait être utile si le message était placé dans une sorte de barre de titre ou autre.
• Avec un point, vous saurez toujours que vous avez une "phrase complète" et elle aura l'air plus finie.

Lequel recommandez-vous ?

Il pourrait également s'agir d'un problème lié aux chaînes de ressources localisées. Il est évident que l'on ne peut pas mettre un point après tout (cela ferait bizarre avec des points après le texte sur les boutons et les éléments de menu, etc.) Mais faut-il alors laisser le point en dehors de tout pour être cohérent et l'ajouter plus tard là où c'est utile ? Ou préférez-vous mettre un point là où cela semble approprié ? Par exemple, après toutes les chaînes de ressources et les messages d'exception qui sont des phrases, mais pas après ceux qui sont des mots. Mais alors, qu'en est-il des phrases très courtes ? Comme "Créer un nouveau fichier", par exemple. On pourrait peut-être aussi omettre les points pour les chaînes qui sont considérées comme des actions... (Je réfléchis pendant que je tape...)

Ce n'est pas la chose la plus importante au monde, je sais, mais ce sont des petites choses comme ça qui ont tendance à m'ennuyer au bout d'un moment. J'aime la cohérence et savoir pourquoi je fais ce que je fais. Le problème, c'est que je ne sais pas lequel choisir :p

Answer 1

Q. Terminez-vous vos messages d'exception par un point ?

De Bonnes pratiques pour les exceptions † sur MSDN dans la section "Créer et lever des exceptions" :

• Utiliser des messages d'erreur grammaticalement corrects, i ponctuation . Chaque phrase de la chaîne de description d'une exception doit se terminer par un point. Par exemple, "T serait une chaîne de description appropriée.

Et en ce qui concerne un éventuel retour d'information à la utilisateur via l'interface utilisateur de l'application, la question comprend :

...Il pourrait également s'agir d'un problème dans les chaînes de ressources localisées.

L'article du MSDN cité en référence ci-dessus indique également :

• Inclure une chaîne de description localisée dans chaque exception. Le message d'erreur que l'utilisateur voit est dérivé de la chaîne de description de l'exception. l'exception qui a été levée, et non de la classe d'exception.

De plus, à partir de Propriété Exception.Message † au début de la section "Remarques" :

Les messages d'erreur s'adressent au développeur qui gère l'exception. Le de la propriété Message doit décrire complètement l'erreur et, lorsque c'est possible, expliquer comment corriger l'erreur. Les gestionnaires d'exception Les gestionnaires d'exception de haut niveau peuvent afficher le message aux utilisateurs finaux. grammaticalement correct et que chaque phrase du message se termine par une se termine par un point. N'utilisez pas de points d'interrogation ou d'exclamation. d'exclamation. Si votre application utilise des messages d'exception localisés, vous devez vous devez veiller à ce qu'ils soient correctement traduits.

---

† .NET Framework 4.6 et 4.5

Answer 2

Oui, je traite généralement les messages d'exception comme des phrases complètes, en les terminant par un point.

Toutefois, le message contenu dans l'exception est destiné au développeur et pas l'utilisateur final . Il se peut très bien que la même exception sous-jacente donne lieu à deux messages différents pour l'utilisateur final, en fonction du contexte dans lequel la méthode d'exception a été appelée.

Vous devriez vraiment présenter à l'utilisateur des messages moins techniques et plus conviviaux.

Answer 3

Les messages d'exception dans le cadre sont terminés par des points ; j'ai tendance à faire de même pour cette raison.
Dans tous les cas, choisissez un style et essayez de vous y tenir...

Answer 4

J'utilise toujours des points dans mes descriptions d'exceptions. En effet, les phrases correctement ponctuées sont plus faciles à lire et plus professionnelles, ce qui est important pour la qualité perçue, n'est-ce pas ?

Comparer avec :

J'utilise toujours des points dans mes descriptions d'exception. Le fait est que les phrases correctement ponctuées sont plus faciles à lire et ont un aspect plus professionnel, ce qui est important pour la qualité perçue, n'est-ce pas ?

Answer 5

Les messages d'exception font partie de l'interface développeur de votre application. Les interfaces sont généralement conçues pour aider l'utilisateur à effectuer une tâche spécifique. Dans le cas d'une exception, l'interface fournie doit être conçue pour transmettre des informations sur une erreur qui s'est produite dans l'application.

Lorsque vous décidez de lever une exception et que vous écrivez une ligne comme

throw new ArgumentException("The string must contain at least one character.");

vous avez déjà pris un certain nombre de décisions concernant l'interface :

• Type d'exception
• Absence de messages d'exception localisés (l'utilisation d'une chaîne codée en dur implique généralement cela)
• Cette exception n'est pas le résultat d'une autre condition (pas d'exception interne).

N'oubliez pas que l'interface développeur existe pour servir les développeurs et l'interface utilisateur pour servir l'utilisateur, les premiers ont des exigences très différentes des seconds, de sorte que ce qui est bon pour l'un peut ne pas l'être pour l'autre, de sorte qu'une période dans le message d'exception ne devrait pas concerner l'interface utilisateur parce qu'elle ne devrait pas être visible pour l'utilisateur final.

L'utilisation d'une période n'est pas une décision majeure dans la plupart des cas, mais vous devez vous demander si sa présence (ou son absence) est bénéfique ou préjudiciable à l'interface en tenant compte des points déjà soulevés, notamment la cohérence du cadre et la localisation.

Je sais que ce billet est un peu verbeux et peut-être un peu astronaute mais j'espère qu'il vous sera utile.