try/catch/finally WTF

[Eddy C. (chrisi)]

Hi Programmierer,

kann mir jemand den Sinn von finally in C# erklären?

Wo liegt der Unterschied zwischen:

  try
  {
     // try something
  }
  catch (Exception)
  {
     // handle something
  }
  finally
  {
     // do what must be done
  }

und

  try
  {
     // try something
  }
  catch (Exception)
  {
     // handle something
  }
  // do what must be done here

Außer, dass es hübscher aussieht?

Ein öfters gesehenes Beispiel im Netz ist auch noch "irritierend" (siehe 
deutscher Kommentar im Quelltext:

void ReadFile(int index)
{
    string path = @"c:\users\public\test.txt";
    System.IO.StreamReader file = new System.IO.StreamReader(path);
    char[] buffer = new char[10];
    try
    {
        file.ReadBlock(buffer, index, buffer.Length);
    }
    catch (System.IO.IOException e)
    {
        Console.WriteLine("Error reading from {0}. Message = {1}", path, e.Message);
    }
    finally
    {
        // Wieso wird file auf null geprüft? file wird außerhalb von
        // try initialisiert und wird daher immer ungleich null sein!
        if (file != null)
        {
            file.Close();
        }
    }
}

Daher hat folgender Code den gleichen Effekt:

void ReadFile(int index)
{
    string path = @"c:\users\public\test.txt";
    System.IO.StreamReader file = new System.IO.StreamReader(path);
    char[] buffer = new char[10];
    try
    {
        file.ReadBlock(buffer, index, buffer.Length);
    }
    catch (System.IO.IOException e)
    {
        Console.WriteLine("Error reading from {0}. Message = {1}", path, e.Message);
    }
    file.Close();
}

Wer kann ein sinnvolles/nützliches Beispiel zu finally zeigen?

[Dennis S. (eltio)]

Bin kein C#-Programmierer, aber die Antwort findest du hier von "Kevin 
Pang":
http://stackoverflow.com/questions/547791/why-use-finally-in-c

The answer is that a lot of times the code inside your catch statement
will either rethrow an exception or break out of the current function.
With the latter code, the "alwaysDoThis();" call won't execute if the
code inside the catch statement issues a return or throws a new
exception.

Gruß
Dennis

[Peter II (Gast)]

Eddy C. schrieb:
> Wo liegt der Unterschied zwischen:

Wenn man nicht alle Exception abfängt oder eine neue Exception wirft.

  try
  {
     // try something
  }
  catch(IOException )
  {
     throw new MyException("sdafasdf");
  }
  finally
  {
     // do what must be done
  }

[Eddy C. (chrisi)]

Dennis S. schrieb:
> Bin kein C#-Programmierer, aber die Antwort findest du hier von "Kevin
> Pang":

Das ist die perfekte Diskussion mit schlüssiger Erklärung!

Peter II schrieb:
> Wenn man nicht alle Exception abfängt oder eine neue Exception wirft.

Jetzt habe ich's :-)

Thanks 2gether!

[Dennis R. (dennis_r93)]

Das geht sogar soweit, dass selbst nach einem return der finally block 
noch ausgeführt wird.

try{
return 0;
}
catch{
return 1;
//oder throw new Exception();
}
finally{
//mach was
}

[Noch einer (Gast)]

Oder falls Console.WriteLine() eine Exception wirft.

Das if (file != null) ? Normalerweise macht man das Open im Try, damit 
das Catch auch die Open-Exceptions bearbeitet. Falls die Exception vor 
dem Open auftritt, schmeißt das Close eine unsinnige Exception.

[Rolf M. (rmagnus)]

finally ist ein Hilfskonstrukt, den man braucht, weil Objekte in C# ihre 
Ressourcen nicht beim Verlassen der Funktion automatisch freigeben.
Das ist der Nachteil, den man sich durch einen Garbage Collector 
einhandelt.

[N. A. (hannilein)]

Sorry, but what does "WTF" mean?
Is that German speak?

[Peter (Gast)]

N. A. schrieb:
> Sorry, but what does "WTF" mean?
> Is that German speak?

No ists English:
http://de.wiktionary.org/wiki/WTF

[rofl (Gast)]

ROFL
Antwort wurde zwar schon gegeben aber da gibt's noch eine C Analogie bei

switch(irgendwas)
{
 case A: machA;
 break;
.
.
.
default: machXYZ
}

/klugscheißende :-P

[Der Andere (Gast)]

Rolf M. schrieb:
> den man braucht, weil Objekte in C# ihre
> Ressourcen nicht beim Verlassen der Funktion automatisch freigeben.

Was ist das für ein Unfug?
Es ist eher eine elegante Methode garantiert Ressourcen freizugeben, die 
eben NICHT automatisch freigegeben werden, auch im Fehlerfall.

Oder wird in deiner Programmiersprache eine Datenbankverbindung, ein 
offenes File oder HTTP oder TCP Verbindung automatisch freigegeben wenn 
du die Funktion/Methode verlässt?

Klar, genau dann wenn du den Rechner ausschaltest :-)

[Peter II (Gast)]

Der Andere schrieb:
> Oder wird in deiner Programmiersprache eine Datenbankverbindung, ein
> offenes File oder HTTP oder TCP Verbindung automatisch freigegeben wenn
> du die Funktion/Methode verlässt?

klar doch. In C++ wird jedes Destuktur bei verlassen vom 
Gültigkeitsbereich aufgerufen.

Damit hat man ein definiertes verhalten, was es (leider) bei C# so nicht 
gibt.

[Mark B. (markbrandis)]

Peter II schrieb:
> Der Andere schrieb:
>> Oder wird in deiner Programmiersprache eine Datenbankverbindung, ein
>> offenes File oder HTTP oder TCP Verbindung automatisch freigegeben wenn
>> du die Funktion/Methode verlässt?
>
> klar doch. In C++ wird jedes Destuktur bei verlassen vom
> Gültigkeitsbereich aufgerufen.

Wenn das Objekt auf dem Stack liegt, ja. Und wieviele Objekte liegen auf 
dem Heap?

[Der Andere (Gast)]

Mark B. schrieb:
> Wenn das Objekt auf dem Stack liegt, ja. Und wieviele Objekte liegen auf
> dem Heap?

Eben, gerade teure Objekte wie DB Verbindungen, TCP verbindungen, etc. 
oft genug nicht.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Mark B. schrieb:

> Wenn das Objekt auf dem Stack liegt, ja. Und wieviele Objekte liegen auf
> dem Heap?

In modernem C++ so gut wie keine. Das spielt aber keine Rolle, solange 
dass Objekt zur Verwaltung der Datenbank-Verbindung auf dem Stack liegt. 
Und in C++ kann man sogar unterbinden, dass solche Objekte auf dem heap 
alloziiert werden.

[Mark B. (markbrandis)]

Torsten R. schrieb:
> In modernem C++ so gut wie keine. Das spielt aber keine Rolle, solange
> dass Objekt zur Verwaltung der Datenbank-Verbindung auf dem Stack liegt.
> Und in C++ kann man sogar unterbinden, dass solche Objekte auf dem heap
> alloziiert werden.

Bei der Masse an real existierenden Speicherlecks scheint es dann wohl 
nicht sehr viel modernen C++ Code zu geben. ;-)

[Michael B. (laberkopp)]

Der Andere schrieb:
> Oder wird in deiner Programmiersprache eine Datenbankverbindung, ein
> offenes File oder HTTP oder TCP Verbindung automatisch freigegeben wenn
> du die Funktion/Methode verlässt?

Na ja, das ist der Grund für Destruktoren und Klassen.

In klassischem C

int func(int param)
{
    char *buffer=malloc(1024);
    if(!buffer) return 0;
    if(!param) // spät entdeckter Fehler
    {
        free(buffer); // ja, hier kann/muss man den Fall extra behandeln
        return 0; // Rückkehr
    }
    use(param,buffer);
    free(buffer);
    return 1;
}

Wenn man eine Programmiersprache mit Exceptions hat, funktioniert kein:

int func(int param)
{
    char *buffer=malloc(1024);
    if(!buffer) return 0;
    if(!param) throw(whatever); // bzw. longjmp(outofhere); in C
    use(param,buffer);
    free(buffer); // oops, not freed after throw/logjmp
    return 1;
}

man braucht Klassen mit Destruktoren, damit der Code gut wird

class staticbuffer
{
    char *ptr;
    staticbuffer() { ptr=NULL; }
    staticbuffer(int size) { ptr=malloc(size); }
    ~staticbuffer() { if(ptr) free(buffer); }
    char *get() { if(ptr) return ptr; else throw(std::bad_alloc()); }
}

void func(int param)
{
    staticbuffer buffer(1024);
    if(!param) throw(whatever);
    use(param,buffer.get());
    // returncode nicht mehr nötig, Fehler=exception
}

Exceptions und Klassen hängen also konzeptionell direkt zusammen.

(Syntaxfehler ungetestet)

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Mark B. schrieb:

> Bei der Masse an real existierenden Speicherlecks scheint es dann wohl
> nicht sehr viel modernen C++ Code zu geben. ;-)

Die Speicherlecks kommen eher aus diesem C-Mit-Klassen Style (wie das 
Beispiel von Michael Bertrandt).

In zwei Projekten, in denen ich den direkten Vergleich hatte, war der 
Server in C++ geschrieben, der Client in einem Fall in Java und im 
anderen Fall in C#. In beiden Fällen, gab es überhaupt kein Problem mit 
Resource-Leakes auf dem Server und die Software lief Wochen und Monate 
ohne Problem durch. Die Clients hatten häufig Probleme mit irgend wo 
vergrabenen Referenzen, die noch erreichbar waren, aber nicht mehr 
erreichbar sein sollten.

Michael Bertrandt schrieb:

> Exceptions und Klassen hängen also konzeptionell direkt zusammen.

Nö, ich benutze im Embedded Bereich Klassen ohne Exceptions. Und 
Exceptions habe ich schon unter VMS implementiert gesehen und die OS-API 
hatte garantiert keine Klassen.

[Rolf M. (rmagnus)]

Der Andere schrieb:
> Rolf M. schrieb:
>> den man braucht, weil Objekte in C# ihre
>> Ressourcen nicht beim Verlassen der Funktion automatisch freigeben.
>
> Was ist das für ein Unfug?
> Es ist eher eine elegante Methode garantiert Ressourcen freizugeben, die
> eben NICHT automatisch freigegeben werden, auch im Fehlerfall.

Richtig. Und in C++ braucht man diese "elegante Methode" nicht. Man hat 
stattdessen Destruktoren, die das auf einem objektorientierten Weg 
umsetzen.

> Oder wird in deiner Programmiersprache eine Datenbankverbindung, ein
> offenes File oder HTTP oder TCP Verbindung automatisch freigegeben wenn
> du die Funktion/Methode verlässt?

Ja. Einfaches Pseudocode-Beispiel:

void readFile(string filename)
{
    File file;
    file.open(filename);
    Buffer buffer = file.readAll();
    Parser parser;
    data_ = parser.parse(buffer);
}

Zugegeben etwas konstruiert, aber man kann sich vorstellen, worauf das 
rauslaufen soll. Mehrere Aktionen werden durchgeführt, und dafür werden 
temporär Ressourcen benötigt, die nachher wieder freizugeben sind.
Wenn die Funktion ihr Ende erreicht oder irgendwo zwischendrin eine 
Exception ausgelöst wird, wird in C++ alles wieder freigegeben. Der 
File-Destruktor kümmert sich dabei darum, nicht nur den Speicher, den 
das File-Objekt selbst für das File-Handle braucht, freizugeben, sondern 
auch die Datei zu schließen. Man muss nicht wissen, daß das Objekt 
intern noch andere Ressourcen als Speicher braucht und sich auch nicht 
explizit darum kümmern, diese von Hand freizugeben. So wird das Prinzip 
der Kapselung besser umgesetzt als in Java oder C#.
Ich kenne das Problem z.B. von Lotus Notes, bei dem beim Laden oder 
Speichern von Mail-Anhängen auf einem USB-Stick dieser nicht sauber 
ausgeworfen werden kann, bis man Notes beendet, da offenbar irgendwo 
vergessen wurde, die Datei wieder explizit zu schließen und diese 
deshalb für immer  (bzw. bis zum Programm-Ende) offen bleibt.
Das ist für mich das Problem mit Garbage Collecoren. Sie kümmern sich 
nicht ganzheitlich um ein vernünfiges Ressourcenmanagement, sondern nur 
um den Speicher. Alle anderen Ressourcen werden nicht automatisch 
freigegeben, und man hat auch keine Möglichkeit, es vernünftig zu 
automatisieren. Und genau deshalb gibt es "finally".

Mark B. schrieb:
>> In C++ wird jedes Destuktur bei verlassen vom Gültigkeitsbereich
>> aufgerufen.
>
> Wenn das Objekt auf dem Stack liegt, ja. Und wieviele Objekte liegen auf
> dem Heap?

Wenn man's richtig macht, nur wenige bis gar keine, um die man sich 
explizit kümmern muss. Dafür gibt's in C++ Container und Smart Pointer.

[Karl H. (kbuchegg)]

Mark B. schrieb:
> Torsten R. schrieb:
>> In modernem C++ so gut wie keine. Das spielt aber keine Rolle, solange
>> dass Objekt zur Verwaltung der Datenbank-Verbindung auf dem Stack liegt.
>> Und in C++ kann man sogar unterbinden, dass solche Objekte auf dem heap
>> alloziiert werden.
>
> Bei der Masse an real existierenden Speicherlecks scheint es dann wohl
> nicht sehr viel modernen C++ Code zu geben. ;-)

Eher gibt es mehr sogenannte C++ Programmierer, die mit dem Begriff 
'RAII' nichts anfangen können. RAII führt recht problemlos zu 
Programmen, die keine Speicherlecks aufweisen. Nur muss man es 
konsequent umsetzen. Und daran hapert es halt meistens (und ich nehme 
mich da durchaus auch nicht davon aus - an der Konsequenz).

[Klopfer (Gast)]

In C# gibt es auch noch "using", damit ist zumindest das explizite 
"finally" bzw. der Aufruf von Dispose/Close (*) unnötig. Man sollte 
natürlich in Klassen, die entsprechende Ressourcen auf Klassenebene 
besitzen, IDisposable implementieren.

(*) Was meistens, aber nicht immer äquivalent ist.

Michael B. schrieb:
> Wenn man eine Programmiersprache mit Exceptions hat, funktioniert
> kein:
> int func(int param)
> {
>     char *buffer=malloc(1024);
>     if(!buffer) return 0;
>     if(!param) throw(whatever); // bzw. longjmp(outofhere); in C
>     use(param,buffer);
>     free(buffer); // oops, not freed after throw/logjmp
>     return 1;
> }

Na ja, so ungefähr:

void func(int param)
{
  auto buffer = std::make_unique<char[]>(1024);
  if(!param) throw(whatever);
  use(param, buffer.get());
}

Was nicht bedeutet, dass man es so machen muss oder sollte.