Appel Console.WriteLine (ex.Message) pour empêcher le message d'avertissement

Question

Nous attrapons généralement l'exception dans le niveau supérieur d'un code comme le GUI (formulaires).

Mais j'ai l'habitude ce genre de code

try 
{ 
} 
catch(Exception ex) 
{ 
    Console.WriteLine(ex.Message); 
    MessageBox.Show("Application has encountered error...."); 
} 

je pouvais attraper (Exception) sans l'identificateur parce que je ne ai pas besoin du message sur l'exécution, mais pour la construction de débogage, il est sûr pratique de rompre à la déclaration de capture. Donc, j'écris habituellement un Console.WriteLine pour éviter beaucoup d'avertissement de la variable ex inutilisée. J'ai beaucoup de cas de Console.WriteLine (ex.Message) dans mon code. Cette performance des coûts diminue-t-elle?

Remarque: Le titre modifié de "Console.WriteLine (ex.Message) a-t-il un coût lié à la performance?" à "Appel Console.WriteLine (ex.Message) pour empêcher le message d'avertissement"

Answer 1

Ceci est un multiple question 1 donc je vais essayer de déroulez:

Tout d'abord

try{ 
    ... 
} 
catch(Exception) 
{ 
} 

est parfaitement syntaxe valide. L'ajout d'une Console.WriteLine (ex.Message) juste pour obtenir la compilation sans avertissement n'est pas la bonne chose à faire.

En second lieu

Console.WriteLine est pas la bonne façon de faire le diagnostic, regardez Trace.WriteLine ou mieux encore Logging framework. Bien sûr, Console.Writeline a un coût, le coût n'est pas trop sérieux, néanmoins un appel est fait, et cela a un coût.

En troisième lieu

Parfois, il est préférable de planter, il vous oblige à résoudre le problème de la racine, au moins faire un Debug.Assert si quelque chose de vraiment mauvais arrive.

Answer 2

Tout a un coût de performance. La question est de savoir si le coût de la performance est important.

Dans ce cas, je pense que les meilleures questions sont où la sortie se passe dans une application winforms, et pourquoi vous affichez uniquement ex.Message et non ex.ToString(). Pourquoi jeter des informations?

Answer 3

Un meilleur choix pourrait être System.Diagnostics.Debug.WriteLine (ex) ou System.Diagnostics.Trace.WriteLine (ex). Le débogage ne fait que quelque chose si le symbole DEBUG est défini et Trace ne fait que quelque chose que TRACE est défini. Par défaut, votre version release n'inclura pas le symbole DEBUG.

Answer 4

Vous pouvez créer une méthode d'extension qui est filtrée en mode débogage.

public static Exception 
{ 

    [Conditional("DEBUG")] 
    public static void Dump(this Exception ex) 
    { 
     Console.WriteLine(ex.ToString()); 
    } 
} 

Ou mieux encore ...

public static Exception 
{ 
    public static void Log(this Exception ex) 
    { 
#if DEBUG 
     Console.WriteLine(ex.ToString()); 
#endif 
     Logger.WriteLine(ex.ToString()); 
    } 
} 

Puis dans votre code à remplacer Console.WriteLine(ex.ToString())ex.Log();

Cependant, en général, l'exception elle-même sera plus d'un problème de performance que le dumping au console.

Answer 5

En C#, il y a un coût qui n'est pas insignifiant lorsqu'on attrape une exception. test pour vous-même, écrire quelque chose comme ceci:

• Créer une liste de chaînes
• Dans cette liste, faire 25% d'entre eux un certain nombre et le reste une seule lettre.
• Exécutez une boucle for en parcourant chaque liste et en faisant un int foo = (int) myList [0] mais en l'enveloppant dans try/catch.

Augmentez le taux jusqu'à 50%, puis 75%, puis 100%. Le 100% sera légèrement plus lent, mais pas de beaucoup.

Dans cet exemple particulier, la réponse du monde réel serait d'utiliser Int32.TryParse à la place, mais cela vous montre la pénalité.

Answer 6

Pour éviter d'obtenir l'avertissement: « La variable « ex » est déclarée mais jamais utilisée » dans une déclaration de capture et également voir les informations associées à l'exception, procédez comme suit:

try 
{ 
    ... 
} 
catch(Exception) // avoid warning 
{ 
    // set break point inside exception 
} 

Définissez un point d'arrêt à l'intérieur de l'exception et observez la variable de débogueur $ exception dans la fenêtre de surveillance rapide, la fenêtre Locals ou la fenêtre de surveillance dans Visual Studio (2008).