finally
Marvin Massih
hier mal etwas Pseudo-Code:
public string GetData()
{
DBSession s = OpenDB();
try
{
string str = s.ReadData();
return str;
}
finally
{
s.Close();
}
return null;
}
Ich finde diesen Code unglaublich unübersichtlich, da ich davon ausgehen
würde, dass die Methode beim ersten return verlassen wird.
Offensichtlich wird s.Close() ja aber ausgeführt.
Ich würde folgendes schreiben:
public string GetData()
{
string retValue = null;
DBSession s = OpenDB();
try
{
retValue = s.ReadData();
}
catch(Exception e)
{
}
s.Close();
return retValue;
}
Nur: Wann sollte man dann überhaupt finally einsetzen?
Tatsächlich habe ich IIRC noch nie finally benutzen müssen.
Gruß
Marvin
Frank Dzaebel
> hier mal etwas Pseudo-Code:
> ... finally {s.Close();}
> Ich finde diesen Code unglaublich unübersichtlich, da ich davon
> ausgehen würde, dass die Methode beim ersten return verlassen wird.
> Offensichtlich wird s.Close() ja aber ausgeführt.
Standard-Vorgehen ist folgendes:
finally { if (s!=null) s.Close();}
[How to: Execute cleanup code using Try/Finally]
http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/1b1e5aef-3f32-4a88-9d39-b5fffb33bdaf.asp
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET
Marvin Massih
Frank Dzaebel wrote:
> Standard-Vorgehen ist folgendes:
> finally { if (s!=null) s.Close();}
> [How to: Execute cleanup code using Try/Finally]
In dem Beispiel gibt es aber kein vorzeitiges return.
Nach dem return könnte ja auch noch anderer Code folgen (wenn das return
nur bedingt ausgeführt wird), evtl. sieht man das finally dann gar nicht
mehr und geht davon aus, dass beim return wirklich zurück gesprungen wird.
Gruß
Marvin
Herfried K. Wagner [MVP]
"Frank Dzaebel" <Po...@FranksSeite.de> schrieb:
>> hier mal etwas Pseudo-Code:
>> ... finally {s.Close();}
>> Ich finde diesen Code unglaublich unübersichtlich, da ich davon
>> ausgehen würde, dass die Methode beim ersten return verlassen wird.
>> Offensichtlich wird s.Close() ja aber ausgeführt.
>
> Standard-Vorgehen ist folgendes:
> finally { if (s!=null) s.Close();}
>
> [How to: Execute cleanup code using Try/Finally]
> http://winfx.msdn.microsoft.com/library/en-us/dv_csref/html/1b1e5aef-3f32-4a88-9d39-b5fffb33bdaf.asp
Das beantwortet doch nicht die Frage, warum man überhaupt 'finally' benutzen
soll. Ärgerlicherweise sind im 'try'-Block deklarierte Variablen nicht in
'finally' sichtbar, was der Atomizität des 'try...catch...finally' im Wege
steht. Zudem wird die Funktion von 'return' verändert, was sicher auch nicht
der Verständlichkeit des Codes zuträglich ist.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Frank Dzaebel
schlaf Dich mal aus ;-)
Halb vier ist auf Dauer gefährlich für die Gesundheit.
Ich denke, es ist sehr sinnvoll, was ich da verlinkt habe.
Wenn es nicht Deinen Geschmack getroffen hat ...
Herfried K. Wagner [MVP]
"Frank Dzaebel" <PostAddFranksSeitePunktDe> schrieb:
> Ich denke, es ist sehr sinnvoll, was ich da verlinkt habe.
Technisch gesehen will ich das nicht bestreiten.
> Wenn es nicht Deinen Geschmack getroffen hat ...
Na, ich hätte mir eine Einschätzung zur Aussage "Ich finde diesen Code
unglaublich unübersichtlich" des OP gewünscht -- die ich mit Einschränkungen
auch teile.
Frank Dzaebel
> Na, ich hätte mir eine Einschätzung zur Aussage "Ich finde diesen Code
> unglaublich unübersichtlich" des OP gewünscht -- die ich mit
> Einschränkungen auch teile.
ja, ich möchte da heute auch noch dazu antworten.
Habe momentan etwas wenig Zeit.
OT: Sollten/können wir uns (beide) vielleicht mal
telefonisch oder Privat-Mail mässig zusammensetzen?
Vielleicht klären sich ein paar Dinge?
Oder einfach mal schnacken, ....
Joachim Fuchs
> telefonisch oder Privat-Mail mässig zusammensetzen?
> Vielleicht klären sich ein paar Dinge?
> Oder einfach mal schnacken, ....
oh - ein öffentliches Blinddate ;-)
Damit Ihr Euch beim Telefonieren auch erkennt:
der Frank:
http://www.franksseite.de/Bilder/Frank_k.jpg
der Herfried:
http://dotnet.mvps.org/meta/author/hkwportrait.jpg
Wünsche einen Exception-freien Gedankenaustausch :-)
Gruß
Joachim
--
Dr. Joachim Fuchs - Autor - Dozent - Softwarearchitekt
MCT - MCAD
http://www.fuechse-online.de/beruflich/index.html -
http://vbnet.codebooks.de
Robert Jordan
> public string GetData()
> {
> DBSession s = OpenDB();
>
> try
> {
> string str = s.ReadData();
> return str;
> }
> finally
> {
> s.Close();
> }
>
> return null;
> }
>
> Ich finde diesen Code unglaublich unübersichtlich, da ich davon ausgehen
> würde, dass die Methode beim ersten return verlassen wird.
> Offensichtlich wird s.Close() ja aber ausgeführt.
Und das?
void Foo()
{
if (nix) return;
Bar();
}
Ich finde diesen Code unglaublich unübersichtlich, da ich davon ausgehen
würde, dass die Methode beim ersten return verlassen wird ;-)
> Nur: Wann sollte man dann überhaupt finally einsetzen?
> Tatsächlich habe ich IIRC noch nie finally benutzen müssen.
Schau dir diese lock(){}-Simulation an:
void Method ()
{
Monitor.Enter(me);
try {
Foo ();
}
finally {
Monitor.Exit(me);
}
}
Egal was in Foo() geschieht, Monitor.Exit wird garantiert aufgerufen
*und* Ausnahmen werden trotzdem propagiert.
Ohne finally müsste man das so schreiben *schauder*:
void Method ()
{
Monitor.Enter(me);
try {
Foo ();
Monitor.Exit(me);
}
catch (Exception ex) {
Monitor.Exit(me);
throw;
}
}
ciao
Robert
Marvin Massih
Robert Jordan wrote:
> void Foo()
> {
> if (nix) return;
> Bar();
> }
>
> Ich finde diesen Code unglaublich unübersichtlich, da ich davon ausgehen
> würde, dass die Methode beim ersten return verlassen wird ;-)
??????
> void Method ()
> {
> Monitor.Enter(me);
> try {
> Foo ();
> }
> finally {
> Monitor.Exit(me);
> }
> }
>
> Egal was in Foo() geschieht, Monitor.Exit wird garantiert aufgerufen
Von der Anwendung habe ich nicht gesprochen, da ist doch gar kein
return, du Nase!
Das leuchtet mir ja ein.
> *und* Ausnahmen werden trotzdem propagiert.
DAS wiederum war mir neu.
Ich beschränke daher meine Aussage aus Situationen, in denen man an der
Exception nicht interessiert ist ;-).
Gruß
Marvin
Robert Jordan
>> {
>> Monitor.Enter(me);
>> try {
>> Foo ();
>> }
>> finally {
>> Monitor.Exit(me);
>> }
>> }
>>
>> Egal was in Foo() geschieht, Monitor.Exit wird garantiert aufgerufen
>
>
> Von der Anwendung habe ich nicht gesprochen, da ist doch gar kein
> return, du Nase!
Dann schreib einen hin.
> Ich beschränke daher meine Aussage aus Situationen, in denen man an der
> Exception nicht interessiert ist ;-).
void Method ()
{
Monitor.Enter();
try {
Foo();
}
catch (Ex1} {
int i = 1;
int j = 0;
Debug.WriteLine(i/j);
}
finally {
Monitor.Exit();
}
}
ohne finally und buggy:
void Method ()
{
Monitor.Enter();
try {
Foo();
}
catch (Ex1} {
int i = 1;
int j = 0;
Debug.WriteLine(i/j);
}
Monitor.Exit();
}
ohne finally nicht buggy:
void Method ()
{
Monitor.Enter();
try {
Foo();
}
catch (Ex1} {
Monitor.Exit();
int i = 1;
int j = 0;
Debug.WriteLine(i/j);
return;
}
Monitor.Exit();
}
Du scheinst davon auszugehen, dass in catch-Blöcke
immer korrekt sind und keine Ausnahmen produzieren.
Marvin Massih
> Du scheinst davon auszugehen, dass in catch-Blöcke
> immer korrekt sind und keine Ausnahmen produzieren.
Das stimmt in der Tat. Danke für den Hinweis.
Was hältst du von meinem ursprünglichen Code?
Marvin