| 

.NET C# Java Javascript Exception

4
Es gibt ja bekanntlich einige Nutzungsmöglichkeiten für Exceptionhandler in C#:

catch(Exception)
{ }

catch(Exception)
{ throw; }

catch(Exception e)
{ Debug.WriteLine(e);}

catch(Exception e)
{ throw new Exception ("fehler!");}

catch(Exception e)
{ MessageBox.Show(e);}

Wann setze ich die jeweils ein?
News:
14.07.2009
jor 781 2 7
jor 781 2 7
1
Für Fall 4 wäre interessant, welchen neuen Exceptiontyp man werfen sollte...
R3d 14.07.2009
1
Fallen euch noch andere Exception-Patterns ein? Die könnten wir hier gleich mit sammeln.
sicco 19.07.2009
In VB.Net gibt es noch die Variante des Exception Filters. Das ganze sieht dann so aus: "Catch ex As System.Runtime.InteropServices.COMException When ex.ErrorCode() = &H80070005". Diese sprachspezifische Besonderheit steht leider nicht in C# zur Verfügung. Mehr dazu: http://blogs.msdn.com/b/toub/archive/2004/03/05/84698.aspx
Floyd 05.01.2011
6 Antworten
5
Ich nummerier meine Antworten einfach mal durch:

1. Niemals in Code, der in ein Produkt eingeht. Dadurch würden Fehler einfach verschlungen. Es ist besser, du fixt die eigentliche Ursache für die Exception, denn sonst wirst du niemals mitkriegen, wenn mal ein neuer Fehler auftritt.
2. Bewirkt exakt 0. Macht niemals Sinn.
3. Verschluckt wie unter 1. alle Fehler, nur dass sie im Visual Studio erscheinen. Nicht viel besser.
4. Besser wäre throw new Exception ("nachricht", e); damit die original-Exception erhalten bleibt. Nummer 4 ist durchaus sinnvoll, um zusätzliche Informationen in die Exception einzufügen.
5. Völlig sinnvoll. Es macht z.B. sinn den Click-Handler eines Buttons in dieses Konstrukt einzuschließen, damit die App nicht crasht, wenn ein Fehler passiert.
14.07.2009
alexander 840 2 9
2
zu 2. Macht schon Sinn, wenn du z.B. noch im Event Log einen Eintrag machen willst, und dann die gesamte Exception inkl. komplettem Stacktrace weiterwerfen willst.

zu 4. Dort wird der komplette Stacktrace gelöscht und dann eine neue Exception geworfen, also sehr fraglich!
Felix 14.07.2009
2
2 macht sinn denn die Exception wird weitergeworfen (inkl. Stacktrace). 4 macht auch Sinn denn die neue Exception wird mit einer InnerExcpetion erstellt und diese enthält alle Infos der ursprünglichen Exception.
gfoidl 30.07.2009
2
2 macht keinen Sinn, warum fangen, nichts machen und wieder werfen? Dann kann ich mir den kompletten Handler gleich sparen!
balu 07.09.2009
4
Noch besser wäre die zu erwarteten Exeptions abzufangen und zu behandeln (z.B. ein TCP-Stream bricht mitten in der Verarbeitung ab oder eine eingehende Verbindung produziert einen Fehler)

try{
listener = new TcpListener(IPAddress.Any, servPort);
listener.Start();
...
}
catch(SocketException ex){
log.ErrorFormat("TCP-Socket-Error bei eingehender Verbindung", ex);
}


Dadurch wird erreicht, das Fehler die nicht vorher behandelbar sind, aber auftreten können, entsprechend behandelt werden, in dem das Ereignis in ein Log geschrieben wird (z.b. mittels Log4Net oder eine einen Log-Klasse). Alle anderen Fehlermeldungen werden weiter an den nächst höheren Exceptionhandler gerreicht.

Das selbe würde man mit diesem Code auch erreichen:

try{
listener = new TcpListener(IPAddress.Any, servPort);
listener.Start();
...
}
catch(SocketException ex){
log.ErrorFormat("TCP-Socket-Error bei eingehender Verbindung", ex);
}
catch(Exception)
{ throw; }


Nur warum sollte ich das tun oder besser gesagt nicht tun:

    1. es sind 2 Zeilen mehr Quellcode die genau das selbe bewirken wie das erste Beispiel.
    2. Der Compiler muss hier zusätzliche Zeilen IL-Code erzeugen und anschließend müßen diese Zeilen auch übersetzt und ausgeführt werden.

Somit ist die Antwort von alexander zu Punkt 2 richtig. Beispiel 2 Macht keinen Sinn und produziert nur unnötigen Code, reduziert die Lesbarkeit bei exesiver Nutzung und geht auf Kosten der Laufzeit.
08.09.2009
Floyd 14,6k 3 9
Floyd 14,6k 3 9
3
Hi,
dennoch ist an einigen Stellen ein erneutes "throw" sinnvoll! Zum Bsp. wenn man nur bestimmte ErrorCodes eines ExceptionHandlers abfangen will. Zum Bsp. ein Timeout usw. andere Fehler aber weiterreichen möchte, damit diese ins Log kommen.

try {
// Logon Ticket Validierung
}
catch(LogonException ex) {
if (ex->code == E_TICKETTIMEOUT) {
// show Logonscreen
setError(E_TICKETTIMEOUT);
showModul("Logon");
}
else {
throw ex;
}
}


MfG
26.10.2009
Blue 321 1 5
1
Nummer zwei und drei würde ich nie ohne sehr guten Grund einsetzen. Am besten ist es, alles in einen einzigen try-catch einzuschließen und die Meldung dem Benutzer anzuzeigen.

Denk dran, dass man Fehler nicht einfach ignorieren sollte, weil die Anwendung dadurch instabil werden kann. Beispiel:

int anzahl = 0;
...
try
{
anzahl++;
openFile(); //Exception möglich
anzahl--;
}
catch {}

Wenn jetzt die Datei nicht geöffnet werden kann, bleibt Anzahl fälschlich stehen.
14.07.2009
ZeroDX 55 1 1
2
als Gegenmaßnahme könnte man in den catch anzahl--; schreiben, um im Fehlerfall den globalen Zustand zu sanieren.
R3d 14.07.2009
2
oder anzahl-- ausschließlich in den finally-Block.
ZeroDX 14.07.2009
0
FlekStore Download for iPhone/iPad. Comfortable with all iOS versions.
15.04.2017
0
You can get free robux online whenever you want to have some generator for the game.
20.04.2017

Stelle deine .net-Frage jetzt!