C# - Try-Catch: Für den Fall der Fälle

Veröffentlicht von Rene Koch am 05.07.2006

(6 Bewertungen)

Durch einen Try Catch Block lässt sich sensibler Code "eingrenzen" und Fehler die sonst das System bzw. das Programm zum absturz bringen würden, lassen sich abfangen und sogar anzeigen.

GFU-Schulungen [Anzeige]

XML und .NET Überblick

Um auf dem neuesten Wissensstand zu sein, sollten Sie unser aktuelles ASP .NET Komplett Seminar belegen.
Nach dem Seminar kennen Sie die wichtigsten Strömungen in der Software-Technologie

Visual Studio Team Foundation Server 2017/2015 (TFS) - Komplett

//Mit einer Try-Klammerung binden wir den unsicheren Code ein

try
{
    //Gerade mein Parsen von Zahlenwerten, passiert es immer wieder...
    string ichBinKeinIntWert = "8a";
    int ichWillEinIntSein = Int.Parse(ichBinKeinIntWert);

    //...schon ist es passiert und es kann bis zum gesamten Absturz des Programmes gehen...
}
    //...aber nicht durch unseren Try-Catch-Block, den das catch fängt den Fehler ab

//Version 1: Mit Exception
catch (Exception ex)
{
   Console.WriteLine(ex.ToString());
   //Vorteil: Genaue Fehleranalyse Möglich durch Ausgabe des Fehlers
   //Nachteil: es wird nur ein Fehler der "Exception" abgefangen (zB kein SQLException)
}

//Version 2: Ohne Exception
catch
{
   Console.WriteLine("Fehler");
   //Vorteil: Fängt alle Fehler ab
   //Nachteil: Keine genaue Fehleranalyse Möglich
}

//So... ich hoffe es ist jedem verständlich.

Abgelegt unter Try, Catch, Fehler, Exception.

6 Kommentare zum Snippet

Michael Roth schrieb am 06.04.2008:

Wer so seine Fehler abfängt, wird irgendwann nicht mehr wissen, was in seiner Applikation oder Assembly passiert.

Man fängt nur die Exception ab, die man auch wirklich behandeln kann! Für alles andere kann man sich der AppDomain.UnhandledException (und ThreadException) bedienen.

Btw.: int liefert auch TryParse (ab .Net 2.0)

Keks1911 schrieb am 05.08.2010:

1 Punkt wegen Pokemon exception handling.

Rainer Hilmer schrieb am 05.08.2010:

Eieieieiei *Daumen runter*

FranzHuber23 schrieb am 31.08.2017:

Wer so seine Fehler abfängt, wird irgendwann nicht mehr wissen, was in seiner Applikation oder Assembly passiert.
Dafür gibt es log4net...

Eieieieiei *Daumen runter*
Jeder sogennante Softwareexperte sagt, man sollte keine Exception generell catchen. Die Wahrheit ist doch: Wer will 32574 verschiedene Exceptions behandeln, wenn es im Endeffekt eh immer darauf rausläuft, dass die Anwendung eine Meldung ausgibt und ins Log schreibt. Falls mir jemand dafür eine bessere Möglichkeit nennen kann, gerne... Ansonsten nicht einfach alles ohne Gegenvorschlag kritisieren.

FranzHuber23 schrieb am 31.08.2017:

Man fängt nur die Exception ab, die man auch wirklich behandeln kann! Für alles andere kann man sich der AppDomain.UnhandledException (und ThreadException) bedienen.

Beim ersten Teil kann ich zustimmen, es macht oft Sinn, bestimmte Exceptions (auch z.B. eigene) zu catchen, allerdings wird man dennoch nachfolgend die allgemeine Exception catchen:


try
{
    //Whatever
}
catch (MyAsdfException asdfEx)
{
   //Show message or whatever
   Console.WriteLine(asdfEx.ToString());
}
catch (Exception ex)
{
   Console.WriteLine(ex.ToString());
}

Koopakiller schrieb am 31.08.2017:

Ich bin der Meinung, dass man sehr stark unterscheiden muss, an was man gerade arbeitet.
Arbeite ich gerade mit Dateien macht es schon Sinn Parse-Exceptions von IO-Exceptions zu unterscheiden, da man dem Benutzer bessere Details liefern kann. Wenn man sicher ist, dass der Anwendungszustand trotz unbekannter Exception gut ist (zurückzuführen auf andere IO Fehler oder was auch immer) kann man noch immer "Unbekannter Fehler" ausgeben.

Am perfekten Gegenbeispiel arbeite ich gerade selbst:
Ein Export-Algorithmus arbeitet bis zu mehreren Minuten und schreibt etliche Dateien. Nun tritt irgend ein Fehler auf...was macht man mit den angefangenen Dateien/Ordnern? Löschen, und das im catch-Handler...auch wenn die Exception danach wieder geworfen wird (in eigener Klasse). (Ja, es gäbe andere Techniken, ist aber so am einfachsten begreifbar.)

Was ein wirkliches Problem darstellt ist allerdings, dass (besonders Anfänger) pauschal überall einen catch-Block drum herum bauen und dann nicht wissen warum das Programm nicht geht. Sollte ein unbehandelter Fehler auftreten, sollte das Programm auch abstürzen. Man kann sonst sowieso nicht nachvollziehen was passiert. (Was ich ganz schlimm finde sind Meldungen wie "Unbekannter Fehler, bitte starten Sie das Programm neu". Sieht Professionel aus, verschleiert nur die Unfähigkeit einen Bug zu fixen bzw. ordentliche Fehlerbehandlung einzubauen)

Alles zu loggen wäre natürlich das beste. Nur manchmal sind Meta-Daten praktisch, dann wären benutzerdefinierte catch-Handler wieder im Vorteil, da man dann teilweise noch extra Daten abfragen kann.

Logge dich ein, um hier zu kommentieren!

C# - Try-Catch: Für den Fall der Fälle

6 Kommentare zum Snippet

Ähnliche Snippets

Suche

Letzte Kommentare