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

[Sir Rufo]

Dann schau dir mal try finally an, denn dafür ist das da.

[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.

[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.