| 

.NET C# Java Javascript Exception

7
was bewirkt try/catch?
News:
10.10.2011
Gast
31 2
4 Antworten
2
Guter Link für eine Einführung in Exceptions in C++. Anzumerken wäre jedoch, dass er eben C++-spezifisch ist, z.B. insofern, als dass man in C++ (im Gegensatz zu Java, C# oder VB.NET, die ich beim Fragesteller eher vermuten würde) beliebige Objekte "werfen" kann, nicht nur solche, die von Exception bzw. Throwable abgeleitet sind.
Matthias Hlawatsch 10.10.2011
2
Mit try/catch klammerst Du einen Codeblock, in dem potentiell eine Ausnahme (Exception) erzeugt werden kann. Wird die Ausnahme erzeugt ("geworfen"), landest Du umgehend im catch-Block und kannst dort auf die "Ausnahme-Situation" reagieren. Wird keine Ausnahme geworfen, läuft der Code normal durch und der catch-Block wird nicht ausgeführt.
10.10.2011
Matthias Hlawatsch 13,2k 4 9
2
Guckst du ins Handbuch oder bei Microsoft!
11.10.2011
Richard 391 7
1
Zu erwähnen ist auch das "Try" in vielen Sprachen auch in Zusammenhang mit einem "Finally" auftreten kann.
Der Try-Block kapselt Code ein in dem es zu Fehler kommen kann. Tritt ein Fehler auf, wird der Code im Catch-Block ausgeführt in sofern ein solcher vorhanden ist. Fehlt dieser, wird der Fehler weiter nach oben gereicht.

Der Code der im Finally-Block steht wird unabhängig davon ob ein Fehler aufgetreten ist oder nicht immer ausgeführt. In diesem kann man nun Ressourcen schließen, Handles freigeben etc.

Ein Beispiel:
var x as new StreamWriter(myStream);
try{
x.Write(bytes);
}
catch(IOException ex){
log.Error("Fehler beim schreiben in den Stream", ex);
}
finally{
x.Dispose();
}


Wobei try+catch, try+finally und try+catch+finally kombiniert werden können.
10.10.2011
Floyd 14,6k 3 9
Gibt es eigentlich auch eine Sprache, die Exceptions anbietet, aber kein finally-Konstrukt? Kann ich mir eigentlich nicht vorstellen.
Was es aber tatsächlich gibt: dass catch und finally nicht (mit dem selben try) kombiniert werden können. In ObjectPascal muss man dafür einen try-catch-Block in einem try-finally verschachteln.
Und schließlich: als Lehrbeispiel ist der Code schön, um zu sehen, was passiert - aber man sollte gleich dazu schreiben, dass anstelle des finally hier ein

using(var x as new StreamWriter(myStream)){...}

die elegantere Alternative wäre.
Matthias Hlawatsch 10.10.2011
using deckt aber nicht alle Möglichkeiten von try..finally ab.
m.fuchs 10.10.2011
using steht nicht in allen Programmiersprachen zur Verfügung. Deswegen hab ich es nicht erwähnt.
Ob es Finally in ALLEN Programmiersprachen gibt weiß ich nicht, von daher wollt es nicht so verallgemeinern. :D
Und drittens, der Pseudocode dient der bildlichen Veranschaulichung.
Floyd 10.10.2011
try..finally gibt es natürlich nicht in allen Sprachen. Genausowenig wie Exceptions überhaupt überall vorhanden sind.
m.fuchs 10.10.2011
@m.fuchs Lies doch bitte etwas genauer. Dass es Sprachen gibt, die keine Exceptions und damit auch kein try/finally haben, ist mir schon klar. Gefragt hatte ich aber nach Sprachen mit Exceptions, aber ohne try/finally. Das kann ich mir nicht sinnvoll vorstellen, aber sicher bin ich mir, so wie auch Floyd, eben nicht.
Und dass using try/finally nicht ersetzt, ist mir auch klar. Ich wollte nur darauf hinweisen, dass das von Floyd verwendete Szenario so häufig vorkommt, dass es (in C#) durch ein eigenes Sprachkonstrukt abgedeckt wird. Und ich finde, dass geht aus meinem Kommentar auch so hervor.
Matthias Hlawatsch 10.10.2011
@Floyd Bis auf das "as" (das ich ehrlich gesagt übersehen habe) ist der Pseudocode korrektes C#, weshalb ich es als ein Beispiel in C# aufgefasst habe.
Matthias Hlawatsch 10.10.2011
@Matthias Hlawatsch: Sorry, da hab ich mich missverständlich ausgedrückt. Ich meinte jetzt nicht dass das finally nur dort nicht vorhanden ist, wo es auch kein Exceptionhandling gibt. Beim nochmal Nachlesen finde ich meinen Text aber auch komisch.

Ada ist beispielsweise eine Sprache die Exceptions und ihre Behandlung kennt, aber ohne finally.
m.fuchs 11.10.2011
3
Der Vollständigkeit halber sei noch erwähnt, dass z.B. das .NET-Framework neben denm "klassischen" 'type-filtered catch-' und 'finally handler' noch zwei weitere exception handler kennt: den 'user-filtered handler' (verfügbar z.B. in VB.Net) und den 'fault handler' (wird nur ausgeführt, wenn eine Ausnahme auftritt).
dkson 11.10.2011
1
Danke für den Hinweis, das wußte ich noch nicht. Hier ein Link zur Beschreibung des User Filtered Handler:
http://msdn.microsoft.com/en-us/library/4dy8x9k9%28v=VS.100%29.aspx
Was genau meinst Du mit "Fault Handler"? Ich finde im .NET-Kontext dazu nur Links zur alten 3.5er Workflow Foundation, aber nichts aktuelles.
Matthias Hlawatsch 11.10.2011
@Matthias: Der FaultHandler ist ein Feature der CommonLanguage Infrastructure, das von C# nicht unterstützt wird. Es ist analog einem finally-Block zu verstehen, der nur dann ausgeführt wird, wenn der try-Block aufgrund einer Exception verlassen wurde. Er wird, soweit ich weiß vor den catch-Handlern ausgeführt. MSIL Anweisung 'fault' hilft für weitere Recherchen.
ffordermaier 11.10.2011
1
@Florian Ok, danke. Mir scheint aber, dass C# den fault durchaus unterstützt. Wenn ich http://weblogs.asp.net/kennykerr/archive/2004/09/15/introduction-to-msil-part-5-exception-handling.aspx richtig verstehe, muß (in MSIL) ein catch einen Exception-Type angeben. In C# kann ich aber auch eine catch-Klausel ohne Exception-Typ verwenden. Das würde dann nach meinem Verständnis auf den Fault-Handler mappen (hab leider grad keine Zeit, es mal auszuprobieren).
Matthias Hlawatsch 11.10.2011
1
Moment, was noch zu beachten wäre: es können (in C#) ja auch spezifische und leere catch-Klauseln zusammen vorkommen, und in MSIL wohl auch catch- und fault-Handler. Mappt das dann trotzdem noch?
Matthias Hlawatsch 11.10.2011
In IL ist ein leerer catch (wie in C#) immer ein
catch [mscorlib]System.Exception
Meines Wissens schließen sich finally und fault gegenseitig aus und fault wird im Gegensatz zu finally vor den catch Handlern ausgeführt. Hab im Moment leider auch keine Zeit, es Du zu überprüfen.
ffordermaier 11.10.2011
Den fault-handler kann man sich vorstellen wie einen catch-Block, der die Exception am Ende wieder wirft. Praktisch gesehen ist das nur ein nice-to-know, da dieser aktuell von keiner .NET-Sprache 'richtig' unterstützt wird. Der C#-Compilier generiert z.B. fault-handler beim Erstellen von Generator-Objekten (durch die Verwendung von yield return).
dkson 11.10.2011

Stelle deine Gui-Frage jetzt!