try .. except .. finally

[Satty67]

Zitat von Surrounder:

Delphi-Quellcode:

begin
   try
     [...]
   except
     AddLogAlert( 'Fehler' );
   finally
     ppFile.Free;
   end;
end;

Wie schon bemerkt wurde, ist das falsch, fände es aber eigentlich ganz praktisch... So in der Art wie If else If Blöcke.

Mal als Erweiterungsvorschlag einreichen... 8)

[mjustin]

Zitat von Muetze1:

Was aber wenn der Speichermanager das Create gar nicht durchführen konnte? Dann ist deine SL Variable so oder so im Eimer, egal wie rum except und finally stehen.

Und umgekehrt: wenn es schon Probleme mit dem Speichermanager gibt, dann spielt der restliche Code auch keine grosse Rolle mehr. Oder wird, damit das QM zufrieden ist, dann ein automatisches Einstecken von mehr RAM Bausteinen ausgelöst ?

SCNR

[Muetze1]

Zitat von mjustin:

Zitat von Muetze1:

Was aber wenn der Speichermanager das Create gar nicht durchführen konnte? Dann ist deine SL Variable so oder so im Eimer, egal wie rum except und finally stehen.

Und umgekehrt: wenn es schon Probleme mit dem Speichermanager gibt, dann spielt der restliche Code auch keine grosse Rolle mehr. Oder wird, damit das QM zufrieden ist, dann ein automatisches Einstecken von mehr RAM Bausteinen ausgelöst ? :)

Wer nun nicht an Beispielen erkennt das die aufgezeigten Probleme auch nur beispielhaft sind, der hat nicht das Prinzip nicht verstanden.

TStringList hat nun nicht soviele mögliche Exceptions und eine Exception im Konstruktor wird von ihr soweit auch nicht verwendet, von daher ist es ein Beispiel gewesen. Es gibt genug Objekte in der freien Wildbahn welche weit andere Exceptions werfen. Und es nochmals daran erinnert, dass die einzige Möglichkeit einen Konstruktor abzubrechen das werfen einer Exception ist und somit hier nicht als Ding der Unmöglichkeit von der Hand zu weisen ist.

Und wenn du QM so witzig findest, scheint dies bei dir/euch wohl auch genauso gehandhabt zu werden und somit ist die Frage was nach deren Prüfung am Ende heraus gegeben wird.

Zitat von Satty67:

Mal als Erweiterungsvorschlag einreichen... 8)

Wurde CodeGear/Embarcardero schon vorgeschlagen und es wird für das nächste Release überlegt, da sie die Sprache samt Compiler eh nochmals umkrempeln.

Christian Seehase

Wie der Name schon sagt, handelt es sich hier um eine Ausnahme, demzufolge finde ich es einfach sauberer mögliche Fehlerbedingungen selber zu prüfen, als es "drauf ankommen zu lassen", und die Programmsteuerung durch Exceptions zu regeln.

Und da liegt der Hund begraben: persönliche Ansichten.

Aber grundlegend hast du vollkommen Recht und ich stimme dir auch voll zu. Die Fehlerbehandlung darf durch die Nutzung der Exceptions nicht gänzlich entfallen, das ist der falsche Weg. Das habe ich so auch nie propagandiert. Eine Exception ist immer eine Ausnahmesituation, aber eine fehlgeschlagene Funktion ist dies noch lange nicht. Von daher ist die normale Fehlerbehandlung weiterhin wichtig und gefordert. Da sind wir uns auch komplett einig, von daher hast du mich vllt. falsch verstanden.

Exceptions sind dazu gedacht auf Situationen hinzuweisen welche so nicht gedacht und/oder geplant waren. Wenn geplant war, dass eine Funktion fehlschlagen kann, dann kann sie ein entsprechenden negativen Rückgabewert o.ä. geben. Eine Exception hingegen weist auf eine ganz andere Situation neben den geplanten Abläufen hin.

Wenn ich eine vom Benutzer ausgewählte Datei öffnen will, dann kann ich mit FileExists() prüfen ob diese existiert. Dann öffne ich sie und gehe auch davon aus diese benutzen zu können. Wenn diese aber durch einen anderen Prozess exklusiv geöffnet ist oder der Nutzer entgegen besseren Wissens uns eine schreibgeschützte Datei zum Speichern ausgewählt hat, so ist dies eine Situation die neben dem geplanten Ablaufstrang liegt. Diese Situation ist eine Exception wert und hier auch sinnvoll. Gerade dies Beispiel zeigt auf, dass man einfach nicht alles durch vorherige Abfragen abprüfen kann. Ich könnte neben FileExists natürlich noch die Attribute prüfen, aber nützt nichts, wenn ich die Datei aufgrund von fehlenden Rechten nicht öffnen kann. Nun gut, wenn ich Zeit habe erkenne ich noch das Dateisystem und checke dann die Rechte der Datei + Rechtekontext in dem die App läuft und dann ob ich damit die Datei öffnen kann. Bringt mir auch noch nichts, wenn ein anderer Prozess diese Datei hat. Ok, also das auch noch abprüfen und dann habe ich ein Problem, wenn der Nutzer auf eine Netzwerkfreigabe gegangen ist, etc, etc, etc.

Grüsse,
Muetze1

[mjustin]

Zitat von Muetze1:

Und es nochmals daran erinnert, dass die einzige Möglichkeit einen Konstruktor abzubrechen das werfen einer Exception ist und somit hier nicht als Ding der Unmöglichkeit von der Hand zu weisen ist.

Das hat ja auch niemand behauptet, mein Beispiel war eventuell nicht minimal genug. Ich wollte damit vor allem nur darstellen, dass die Reihenfolge finally ... except eher ungünstig ist. Dass in meinem Beispiel auch noch andere Dinge enthalten waren, über die sich trefflich streiten lässt, hat den Blick auf die Kernfrage (zuerst das finally, oder erst das except?) etwas verstellt.

Cheers,

[Muetze1]

Zitat von mjustin:

Zitat von Muetze1:

Und es nochmals daran erinnert, dass die einzige Möglichkeit einen Konstruktor abzubrechen das werfen einer Exception ist und somit hier nicht als Ding der Unmöglichkeit von der Hand zu weisen ist.

Das hat ja auch niemand behauptet, mein Beispiel war eventuell nicht minimal genug. Ich wollte damit vor allem nur darstellen, dass die Reihenfolge finally ... except eher ungünstig ist. Dass in meinem Beispiel auch noch andere Dinge enthalten waren, über die sich trefflich streiten lässt, hat den Blick auf die Kernfrage (zuerst das finally, oder erst das except?) etwas verstellt.

Ich verstehe dich dann nicht. Gerade dein Beispiel mit dem äusseren except Block und der Nutzung der Variablen im Exception Handler stellt doch das Problem dar: du benutzt eine Variable die nicht sicher ist, da die Exception eine Initialisierung der selbigen verhindert hat.

Und gerade dadurch wird die Kernfrage doch schon geklärt: Wenn du Dinge aus dem inneren Block nutzen willst, dann muss der Except Block innerhalb von finally stehen. Wenn aber nicht, dann lieber ausserhalb, weil sonst die Gültigkeit der lokalen Daten welche mit finally definitiv freigegeben werden sollen, unnötig verlängert wird.

[Christian Seehase]

Moin Muetze,

Zitat von Muetze1:

Da sind wir uns auch komplett einig, von daher hast du mich vllt. falsch verstanden.

Ich denke nicht, dass ich Dich falsch verstanden habe.
Du wolltest ja nur eine Begründung habe, warum ich der Ansicht bin, dass man Exceptions nur Ausnahmsweise verwenden sollte

@Michael:
Schon klar, dass eine nicht ausgelöste Exception das Programm nicht verlangsamt.
Ich habe nur schon gesehen, dass diese intensiv benutzt werden um, oft simple, Prüfungen zu ersetzen, so dass die Exceptions recht häufig geworfen werden, und dann kann es sich durchaus als Bremse erweisen.

[Surrounder]

Dass ich jetzt so eine Diskussion vom Zaun breche wollte ich nicht, also vertragt Euch wieder

Zitat von Muetze1:

Wenn ich eine vom Benutzer ausgewählte Datei öffnen will, dann kann ich mit FileExists() prüfen ob diese existiert. Dann öffne ich sie und gehe auch davon aus diese benutzen zu können. Wenn diese aber durch einen anderen Prozess exklusiv geöffnet ist oder der Nutzer entgegen besseren Wissens uns eine schreibgeschützte Datei zum Speichern ausgewählt hat....

Das was Muetze1 beschrieben hat trifft bei mir exakt zu, ich prüfe natürlich mit FileExists ob die Datei auch wirklich da ist, öffne Sie dann und versuche dann meine Daten zu schreiben. Die Datei gibt es auch, aber der User hat keine Rechte auf dem Pfad und ich kann die Datei zwar öffnen, aber eben nicht den Inhalt schreiben.
Mir war es nun genau zu viel Aufwand hier sämtliche Dinge zu prüfen, da es sich sowieso um eine Ausnahmesituation handelt wollte ich das als Excpetion abfangen. Ich komme ansonsten halt vom 100ten ins 1000ste und bin nur noch am prüfen und machen bevor ich zum eigentlichen Sinn meiner Software komme.

Meine Frage war ja auch nur warum ich keinen try .. except .. finally Block machen kann, weil mir das in diesem Moment einfach logisch erschien. Ich habe aber nun verstanden dass die Syntax das eben nicht vorsieht

[alzaimar]

Wir hatten schon diverse Diskussionen zum Thema 'Exceptions: Geißel oder Segen?'. Oder auch: 'Oute ich mich als Versager, wenn ich mit Try..Except arbeite'.

Ich werde mal wieder meine Meinung zum Besten geben:
Ein Grundsatz robuster Softwareentwicklung ist, das innere Exceptions nicht nach außen dringen sollen. Ich muss also *alle* Exceptions abfangen, behandeln und ggf. in andere Exceptions übersetzen. Jede öffentliche Klasse sollte auch einen Satz von eigenen Exceptions mitbringen, in die die inneren Exceptions ggf. übersetzt werden.

Was bringt dem Anwender eine Exception der TCP-Klasse? Er versteht sie nicht, er wollte mit TCP nix am Hut haben, also: Gar nichts. Ihm ist es auch egal, das der Programmierer einen SQL-Befehl falsch geschrieben hat. Er will klare und verständliche Fehlermeldungen. in der Logdatei kann der Fehler ja stehen, aber nicht auf dem Bildschirm.

Für mich (und u.A. auch die Erfinder moderner Programmiersprachen) sind Try-Except Blöcke ein Segen, denn sie erlauben mir, einen klaren Programmfluss, der eben nicht durch ständige Abfragen von Präkonditionen unleserlich gemacht wird. Denn Eine Exception ist die Ausnahme, der Code wird also i.d.R. so abgearbeitet, wie ich es wollte, nur eben in Ausnahmen nicht. Die sind i.d.R. gravierend und führen dann zum Abbruch der Aktion.
D.h. natürlich nicht, das ich auf sämtliche Präkonditionen verzichte, aber da ich sowieso nicht alle Fehler von vorne herein abfangen kann, beschränke ich mich auf die, die den Code leserlicher machen.

Beispiel: Ich kann schauen, ob eine Datei, aus der ich lesen will, existiert. Aber wozu soll ich vorher prüfen, ob die Datei korrupt ist? Da lass ich den Karren doch lieber an die Wand fahren und kratze die überbleibsel ab und analysiere sie.

Gut, Try-Except macht also Sinn. Alle sichtbaren Methoden sind mit einem Try-Except-Block gekapselt, und sei es, um die Logdatei zuzumüllen.

Das ich zudem in den meisten Methoden irgendwelche Klassen instantiiere, die ich im Finally-Block wieder freigebe, folgt daraus, das alle Methoden nach dem Motto: Reservieren-Ausführen-Fehler behandeln-Freigeben implementiert werden.

Delphi-Quellcode:

Try
 ...
Except
  LogDenFehler;
Finally // << --- unnötig
  WaschDieHände;
End;

Ist hübsch aber überflüssig, denn der Fehler wird nicht weitergereicht, also braucht man auch den Finally-Block nicht.

Ich konvertiere Fehler und leite sie weiter, denn Fehler sind schwerwiegend und keine Bagatelldelikte. Also wäre mir ein kompakter Try-Except-Finally-Block angenehm.

Delphi-Quellcode:

Try
 ...
Except
  LogDenFehler;
  LeiteIhnWeiter; // <<---
Finally
  WaschDieHände;
End;

Ich nehme mal an, die Java- und C#-Erfinder haben sich so etwas ähnliches dabei gedacht, also sie die kombinierten Try-Catch-Finally-Blocke ins Sprachkonzept aufgenommen haben. Das sie bei Delphi fehlen, ist schade, aber es gibt Schlimmeres.

[GreenHorn3600]

Zitat von angos:

Delphi-Quellcode:

[...]
begin
   ppFile := TNativeXml.CreateName('xyz');
   try
      try
         [...]
      except
         AddLogAlert( 'Fehler' ); //<< Was passiert, wenn hier ein Fehler auftaucht?
      end;
   finally
      ppFile.Free;
   end;
end;

Was mich Interessieren würde ist, was passiert, wenn im AlertLog ein Fehler auftritt, z.B. weil der Arbeitsspeicher aus ist oder die Platte korrupt und das Finally weggelassen wurde. Werden dann dennoch die Ressourcen freigegeben oder verbleiben die im Speicher?

Nachdenkliche Güße
GreenHorn

[himitsu]

wenn in AddLogAlertein Fehler auftritt, dann wird ppFile immernoch freigegeben
und danach die Exception von AddLogAlert nach außen weitergereicht.