Exception.Message vs Exception.ToString ()

Question

J'ai un code qui est journalisation Exception.Message. Cependant, j'ai lu un article qui stipule qu'il est préférable d'utiliser Exception.ToString(). Avec ce dernier, vous retenir plus d'informations cruciales sur l'erreur.

Est-ce vrai et est-il sûr d'aller de l'avant et de le remplacer tout le code de journalisation Exception.Message?

Je suis également en utilisant une base de XML de mise en page pour log4net. Est-il possible qu' Exception.ToString() peut contenir des caractères XML non valides, ce qui peut causer des problèmes?

Answer 1

Exception.Message ne contient que le message (doh) associée avec l'exception. Exemple:

La référence d'objet n'est pas définie à une instance d'un objet

L' Exception.ToString() méthode donnera beaucoup plus de commentaires de sortie, contenant le type d'exception, le message d'avant), une trace de la pile, et toutes ces choses de nouveau pour imbriquée/exceptions internes. Plus précisément, la méthode renvoie la suivante:

ToString retourne une représentation de l'exception en cours qui est destiné à être compris par l'homme. Où l'exception contient sensible à la culture, de données, la représentation de chaîne retournée par ToString est nécessaire de prendre en compte le système actuel de la culture. Bien qu'il n'existe pas d'exigences précises pour le format de la chaîne de retour, il doit tenter de tenir compte de la valeur de l'objet, telle que perçue par l'utilisateur.

L'implémentation par défaut de ToString obtient le nom de la classe qui a jeté l'exception en cours, le message, le résultat de l'appel à ToString sur l'exception interne, et le résultat de l'appel d'Environnement.StackTrace. Si l'un de ces membres est référence null (Nothing en Visual Basic), sa valeur n'est pas incluse dans la chaîne renvoyée.

Si il n'y a aucun message d'erreur ou si c'est une chaîne vide (""), alors pas de message d'erreur est retourné. Le nom de l'exception interne et la trace de la pile sont renvoyés que s'ils ne sont pas une référence null (Nothing en Visual Basic).

Answer 2

En plus de ce qui a déjà été dit, ne pas utiliser ToString() sur l'objet de l'exception pour l'affichage à l'utilisateur. Juste l' Message de la propriété devrait suffire, ou un niveau plus élevé de message personnalisé.

Dans les conditions de l'exploitation forestière, certainement utiliser ToString() sur l'Exception, et pas seulement l' Message de la propriété, comme dans la plupart des scénarios, vous serez à gauche rayer votre tête où précisément cette exception s'est produite, et ce à l'appel de la pile. La stacktrace aurait dit tout ce qu'.

Answer 3

Je dirais @Wim est droit. Vous devez utiliser ToString() pour les fichiers de log - en supposant une technique de public - Message, le cas échéant, à afficher à l'utilisateur. On pourrait arguer que même cela n'est pas approprié pour un utilisateur, pour chaque type d'exception et occurance (pensez à ArgumentExceptions, etc.).

Aussi, en plus de la StackTrace, ToString() inclura des informations que vous ne sera pas obtenir autrement. Par exemple, la sortie de la fusion, si activé pour inclure les messages de log dans d'exception "messages".

Certains types d'exception même inclure des informations supplémentaires (par exemple des propriétés personnalisées) en ToString(), mais pas dans le Message.

Answer 4

Dépend de l’information dont vous avez besoin. Pour le débogage de la stack trace & exception interne sont utiles :

Answer 5

En ce qui concerne le format XML de log4net, vous devez vous inquiétez pas, ex environ. ToString() pour les journaux. Il suffit de passer l’objet exception lui-même et log4net fait le reste vous donnent tous les détails dans son format XML préconfigurée. La seule chose que je rencontrerai à l’occasion est mise en forme de nouvelle ligne, mais c’est quand je lis les fichiers raw. Dans le cas contraire l’analyse XML fonctionne très bien.