Console.WriteLine (ex.Message) aufrufen, um Warnmeldung zu vermeiden

Question

Wir fangen normalerweise Ausnahme in der oberen Ebene eines Codes wie der GUI (Formulare).

Aber ich habe in der Regel diese Art von Code

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

ich gerade (Exception) ohne Kennung fangen konnte, weil ich die Nachricht zur Laufzeit nicht brauchen, aber für das Debugging zu bauen, es ist sicher, bequem zu Pause bei der Fangmeldung. Daher schreibe ich in der Regel eine Console.WriteLine, um zu verhindern, dass eine ungenutzte ex-Variable zu oft gewarnt wird. Ich habe eine Menge von Console.WriteLine (ex.Message) in meinem Code. Verringert sich die Kostenleistung?

Hinweis: Geänderter Titel von "Hat Console.WriteLine (ex.Message) Leistungskosten?" zu "Calling Console.WriteLine (ex.Message), um Warnmeldung zu verhindern"

Answer 1

Dies ist eine mehrere Frage in 1 so werde ich versuchen, es entrollen:

Zur einer

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

Ist absolut gültige Syntax. Es ist nicht das Richtige, eine Console.WriteLine (ex.Message) hinzuzufügen, nur um das Ding ohne Warnung zu kompilieren.

Zweitens

Console.WriteLine ist nicht der richtige Weg, Diagnostik zu tun, schauen Trace.WriteLine oder besser noch ein Logging framework. Natürlich hat Console.Writeline Kosten, die Kosten sind nicht zu ernst, nichtsdestoweniger wird ein Anruf getätigt, und das hat Kosten.

Drittens

Manchmal besser seine abstürzen, es zwingt Sie das eigentliche Problem zu beheben, zumindest tun ein Debug.Assert, wenn etwas wirklich Schlimmes passiert.

Answer 2

Alles hat einen Leistungsaufwand. Die Frage ist, ob die Leistungskosten signifikant sind.

In diesem Fall denke ich, die besseren Fragen sind, wo die Ausgabe in einer Winforms-Anwendung geht, und warum Sie nur ex.Message und nicht ex.ToString() anzeigen. Warum Informationen wegwerfen?

Answer 3

Eine bessere Wahl könnte System.Diagnostics.Debug.WriteLine (ex) oder System.Diagnostics.Trace.WriteLine (ex) sein. Debug tut nur etwas, wenn das DEBUG-Symbol definiert ist und Trace nur etwas tut. TRACE ist definiert. Standardmäßig enthält Ihr Release-Build kein DEBUG-Symbol.

Answer 4

Sie können eine Erweiterungsmethode erstellen, die im Debug-Modus herausgefiltert wird.

public static Exception 
{ 

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

Oder noch besser ...

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

Dann im Code Console.WriteLine(ex.ToString()) zu ex.Log();

ersetzen Ausnahme in der Regel selbst wird jedoch eher ein Performance-Problem als das Dumping Konsole.

Answer 5

In C# gibt es Kosten, die beim Eintreffen einer Ausnahme nicht unbedeutend sind. Testen Sie es selbst, so etwas schreiben:

• Erstellen Sie eine Liste von Strings
• In dieser Liste machen 25% von ihnen eine Zahl und der Rest ein einzelner Buchstabe.
• Führen Sie eine for-Schleife durch jede Liste und tun ein int foo = (int) myList [0] aber wickeln Sie es in try/catch.

Erhöhen Sie die Rate auf 50%, dann 75%, dann 100%. Die 100% werden etwas langsamer sein, aber nicht viel.

In diesem speziellen Beispiel wäre die reale Antwort stattdessen Int32.TryParse, aber das zeigt Ihnen die Strafe.

Answer 6

zu vermeiden Um die Warnung zu bekommen: „Die Variable‚ex‘deklariert, aber nie verwendet“ in einer catch-Anweisung, und auch die Informationen mit Ausnahme zugeordnet ist, um zu sehen, gehen Sie wie folgt vor:

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

Legen Sie innerhalb der Ausnahme einen Unterbrechungspunkt fest, und sehen Sie sich die Debugger-Variable $ exception in dem Schnellüberwachungsfenster, dem lokalen Fenster oder dem Überwachungsfenster in Visual Studio (2008) an.