Quel style utilisez-vous pour les messages d'exception? [fermé]

Question

En écrivant le code qui lève l'exception, j'ai posé une question à propos de ici , je suis arrivé à la fin de mon message et j'ai fait une pause à la ponctuation. J'ai réalisé que presque tous les messages d'exception que j'ai jamais lancés ont probablement un! quelque part.

throw new InvalidOperationException("I'm not configured correctly!");
throw new ArgumentNullException("You passed a null!");
throw new StupidUserException("You can't divide by 0!  What the hell were you THINKING???  DUMMY!!!!!");

Quel ton prenez-vous lorsque vous écrivez des messages d'exception? Lorsque vous parcourez les journaux, trouvez-vous qu’un certain style de message est plus utile qu’un autre?

Answer 1

Une tonalité de conversation dans les messages système donne au logiciel une apparence peu professionnelle et bâclée. Les points d'exclamation, les insultes et l'argot n'ont pas vraiment leur place dans les messages d'exception polis.

De plus, j’ai tendance à utiliser différents styles en Java pour les exceptions d’exécution et les exceptions vérifiées, car les exceptions d’exécution sont adressées au programmeur qui a commis l’erreur. Comme des exceptions d’exécution peuvent être affichées pour les utilisateurs finaux, j’ai toujours "le garder propre", mais ils peuvent être un peu plus laconiques et énigmatiques. Les messages d’exception cochés devraient être plus utiles, car il se peut que l’utilisateur puisse résoudre le problème si vous le décrivez (par exemple, fichier non trouvé, disque plein, pas de route à héberger, etc.).

Une donnée utile, en l'absence d'un champ spécifique sur l'exception pour l'information, est la donnée incriminée:

throw new IndexOutOfBoundsException("offset < 0: " + off);

Answer 2

Soyez juste un fait. Incluez toutes les informations dont vous aurez probablement besoin lors du débogage, mais pas plus que cela.

Un message d'exception n'inclut un point d'exclamation que s'il indique que quelque chose de vraiment, vraiment bizarre s'est passé. La plupart des erreurs ne sont pas vraiment bizarres, elles sont simplement le produit d'un environnement incorrect, d'une erreur d'utilisateur ou d'une simple erreur de programmation.

Answer 3

J'essaie de refléter le ton, la grammaire et le style de ponctuation du cadre sur lequel je code. Vous ne savez jamais à quel moment l'un de ces messages pourrait être affiché devant un client ou un utilisateur. Je garde donc tout ce qui est professionnel, non critique et suffisamment précis pour le dépannage - sans être suffisamment précis pour laisser de côté les problèmes de sécurité. code.

J'évite les points d'exclamation dans toutes les chaînes (UI et exception) comme la peste, sauf (occasionnellement) dans mes tests unitaires.

Answer 4

Prendre la responsabilité, même lorsque c’est vraiment la faute de l’utilisateur, est la meilleure option que j’ai vue.

Des choses du genre "Je ne trouve pas le fichier que vous vouliez, voulez-vous vérifier si je l’ai bien?" ou "Quelque chose s'est mal passé. Je ne sais pas quoi, mais le seul moyen de remédier à la situation est de m'arrêter. Merci de me redémarrer. & Quot;

Answer 5

Des informations concises, détaillées et peu redondantes (par exemple, ArgumentNullException impliquait évidemment une valeur null).

Mais voici le meilleur que j'ai lu depuis un moment, répondez d'abord à this .

Answer 6

Je n’utiliserais pas trop les points d’exclamation. Ils expriment trop, pensez au fait que "Pas de disque dans le lecteur!" peut être lu comme "Aucun disque dans le lecteur ne vous rend fou d'utilisateur". ;)

Je pense qu'il est sage de créer des exceptions contenant un texte internationalisé. Vous ne savez jamais qui va utiliser votre code, intercepter votre exception et afficher le texte à l'utilisateur. Donc, ce serait:

throw new MagicalException(getText("magical.exception.text"));

Je vous recommande également d'encapsuler l'exception sous-jacente (si vous en avez une) lorsque vous la lancez. Cela aide vraiment le débogage.

Ne pensez pas que les exceptions d'exécution ne seront pas vues par l'utilisateur. Si vous vous connectez à un importateur de fichiers, un utilisateur curieux pourrait simplement ouvrir le journal et jeter un œil à vos secrets sales .

Answer 7

Je trouve que les messages les plus utiles sont les suivants:

• Un format cohérent qui facilite la compréhension de ce qu’ils vous disent.
• Un horodatage, pour que vous puissiez avoir une idée de la dynamique de votre programme.
• Résumé du résumé de l’erreur. Si vous fournissez un support technique, ajoutez un code d'erreur pour une identification rapide.
• Une explication de ce qui ne va pas, une distinction entre une entrée utilisateur non valide et une erreur de codage.
• Informations détaillées , y compris la ligne de code ou les valeurs concernées.

Et le plus important:

• Ils indiquent à l'utilisateur comment résoudre le problème.

Exemple:

Error 203 (Timeout) in commit.c line 42:
Unable to save salary data for user 'Linus' to database at '10.10.1.21'
after 1500ms.  Verify database address and login credentials.

L’une des leçons les plus difficiles à apprendre est que vos utilisateurs sont beaucoup moins intéressés par les éléments internes de votre code que par le fait de faire leur travail. Faites-leur aussi simple que possible de le faire. leurs emplois, et vous avez ajouté une valeur énorme à votre logiciel.

Answer 8

J'ai tendance à intégrer mes messages d'exception à l'exception eux-mêmes. Par exemple. un fichier non trouvé devrait dire "fichier non trouvé". Des données spécifiques ne doivent être incluses que si l'utilisateur ne peut pas les comprendre; dans ce cas, l'utilisateur connaît le nom du fichier, donc je n'ajoute pas ces données. Le formatage peut être effectué à l'aide de n'importe quelle sortie d'informations si nécessaire, aussi j'essaie de les rendre aussi favorables que possible au reformatage.

Answer 9

Poli, concis, simple, spécifique. Il est souvent utile d’inclure des valeurs d’état dans un message.