Objekte einer TObjectList direkt aus dem Speicher lesen / in ihn schreiben

[Benmik]

Ja. Nur dass dann bei einer Exception der Code durchläuft und Result damit True ist.
Ich habe jetzt zu einem Sprunglabel gegriffen. Bei dem "exit" da oben kommt es ja auch zu einem Speicherleck.

[Sir Rufo]

Nein, tut er nicht.

http://www.delphi-treff.de/tutorials.../exceptions/5/

[Benmik]

Zitat von Sir Rufo:

Nein, tut er nicht.

Ich fasse es nicht. Warum sagt einem sowas keiner?
Ich habe gerade noch ein bisschen gesucht. Nirgendwo wird man explizit darauf hingewiesen, dass es nach einer Exception nach dem Finally nicht weitergeht.
Ich verstehe übrigens nicht, warum es nach all den vielen Jahren immer noch kein Try...except...finally...end gibt. Man muss immer noch einen Block zwischen Try und Finally dazwischenklemmen.

[Sir Rufo]

Nirgendwo?

http://docwiki.embarcadero.com/RADSt..._try...finally

try finally (ist nicht auf Delphi beschränkt und funktioniert überall gleich)

[Benmik]

Irgendwo bestimmt, aber auch in deiner Zitatstelle finde ich das nicht.

[BUG]

Gar nicht so schwer zu finden.

Zitat von Exceptions (Delphi):

Bei einer Exception wird die Steuerung an Anweisungsliste2 übergeben und danach die Exception erneut ausgelöst.

Aber das muss man tatsächlich einmal gehört haben, um es zu wissen. Mich hatte das damals auch überrascht, als ich es das zum ersten Mal gehört habe

[Uwe Raabe]

Zitat von Benmik:

Irgendwo bestimmt, aber auch in deiner Zitatstelle finde ich das nicht.

Nicht?

Zitat:

Bei einer Exception wird die Steuerung an Anweisungsliste2 übergeben und danach die Exception erneut ausgelöst.

ergänzt durch ganz oben in dem Artikel

Zitat:

Eine Exception wird ausgelöst, wenn die normale Programmausführung durch einen Fehler oder ein anderes Ereignis unterbrochen wird. Die Steuerung wird dadurch an eine Exception-Behandlungsroutine übergeben.

[Benmik]

Na ja, nach dem Hinweis von Sir Rufo war die besagte Textstelle natürlich das Erste, was mir ins Auge gefallen ist. Ich möchte aber auf das "explizit darauf hingewiesen" abheben. Nachdem ich den Sachverhalt kannte, habe ich auch die Textstelle verstanden. Es sollte aber umgekehrt sein!
Wie bestimmt zahllose andere vor mir habe ich mir ein kleines Beispielprogramm (natürlich Divison durch Null) aufgesetzt, um die Sache zu verstehen. Ich denke, bei so ganz alte Hasen wie Sir Rufo und Uwe Raabe sind diese Dinge längst so verinnerlicht, dass sie die Irrwege von nicht so Beschlagenen nicht ganz nachvollziehen können. Natürlich steht das alles da, aber Meister der Didaktik sind weder bei Embarcadero noch bei Microsoft zu finden. Bei msdn werden die Erklärungen der API-Funktionen nicht umsonst regelmäßig von Kommentaren von Anwendern begleitet.
Vielleicht fehlen mir die höheren Weihen, aber ich finde die Exception-Behandlung einfach bescheuert.
Bei

Delphi-Quellcode:

Try
...
Finally
...
End

ist zwar gesichert, dass ein bestimmter Code (Speicherfreigabe wohl in der Regel) ausgeführt wird, aber es knallt nach wie vor, da in Finally keine Exception-Behandlung enthalten ist. Soweit ich das sehe, ist es auch bei dem Codebeispiel von Sir Rufo so, dass das Programm anhält, wenn es knallt, da es ja kein Except gibt (oder???).
Das Ganze ist ja schon oft in der DP diskutiert worden. Der Standardvorschlag ist doch

Delphi-Quellcode:

Try
  Try
  ...
  Except
  ...
  End
Finally
...
End;

Dann aber läuft der Code über das Finally hinaus, weil die Exception ja behandelt ist, und man muss irgendwie hinbekommen, dass Result dann trotzdem FALSE ist. Vermutlich durch ein Exit nach dem Except? Eingängig ist das nicht. Wirklich was für die guten alten Real Programmer.
Sir Rufo hat aus meiner Function eine Procedure gemacht, was hier nicht in meinem Sinn ist, da ich wissen möchte, ob das Einlesen funktioniert hat. Wenn nicht (weil es noch keine DB gibt, die DB veraltet ist oder aus sonstigen Gründen), werden die Vorschaubilder neu erzeugt.
Ansonsten wollte ich noch einiges an Fehlerbehandlung einfügen, aber nach der Kopfsteh-Problematik ging es erstmal um die Machbarkeit.
In jedem Fall habe ich wieder was gelernt, danke dafür.

[Perlsau]

Zitat von Benmik:

Ja. Nur dass dann bei einer Exception der Code durchläuft und Result damit True ist.
Ich habe jetzt zu einem Sprunglabel gegriffen. Bei dem "exit" da oben kommt es ja auch zu einem Speicherleck.

In diesem Fall verwendet man die Try-Finally-Variante:

Delphi-Quellcode:

function TBilderListe.LeseVSBAusDatei(Dateiname: string): Boolean;
var BildNr,AnzDS:integer; Stream,VSBStream:TMemoryStream; VSBBmp:TBitMap; VSBHöhe:integer;
const PosBiHeight = 14 + 4 + 4;
begin
  Result := False;
  If not FileExists(Dateiname)
    then exit;
  Stream := TMemoryStream.Create;
  Try
    Stream.LoadFromFile(Dateiname);
    Result := True;
  Finally
    Stream.Free;
  End;
  If Not Result Then Exit;
  ...

Wenn das Laden der Datei in den Stream schiefläuft, bleibt Result = False und somit wird die Methode nach dem Try-Finally-Block mit Exit verlassen. Normalerweise kann hier nichts schieflaufen, da ja die Existenz der Datei zuvor abgefragt wird. Einzige Fehlerquelle, die mir jetzt noch einfällt: Die Datei ist zu groß für den verfügbaren Arbeitsspeicher. Ich verwende daher immer noch einen Try-Except-Block innerhalb des Try-Finally-Blocks, um die Fehlermeldung zu erhalten, die in eine globale Fehlervariable geschrieben wird. Aber das kannst du letztendlich halten, wie du willst ...

[BUG]

Zitat von Perlsau:

Einzige Fehlerquelle, die mir jetzt noch einfällt: Die Datei ist zu groß für den verfügbaren Arbeitsspeicher.

Mir fallen noch einige ein: die Datei wurde zwischendurch gelöscht, umbenannt, der USB-Stick wurde gezogen; oder es fehlen die nötigen Zugriffsrechte.