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

[Benmik]

Zitat:

Zitat von Sir Rufo (Beitrag 1326459)

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:

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 :wink:

[Perlsau]

Zitat:

Zitat von BUG (Beitrag 1326462)

Zitat:

Zitat von Perlsau (Beitrag 1326461)

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.

Da mußt du aber ganz ganz flink im Millisekundenbereich sein, wenn du zwischen dem Testen auf Existenz und dem Beginn des Einlesen noch schnell den Datenträger entfernen willst. Während des Einlesens dann schon eher ... Übrigens sollte man USB-Sticks ebenso wie USB-Platten niemals einfach so abziehen, sondern diese zuvor abmelden. Und da erhält man dann die Meldung, daß das nicht geht, weil der Datenträger noch in Verwendung ist. Wie schützt man ein Programm vor dem Betätigen des Ausschalters?

[Sir Rufo]

Sagen wir mal so: Wenn es die Datei eben noch gegeben hat, dann kann diese jetzt schon wieder über den Jordan sein. Wozu also der "DoppelTest" (Prüfen und beim Laden wird auch geprüft), wenn die Routine eh abgebrochen werden soll?

Ich würde da gar nicht so einen Aufriss von machen:

Delphi-Quellcode:

procedure TBilderListe.LeseVSBAusDatei(Dateiname: string);
var 
  BildNr,AnzDS: integer; 
  Stream,VSBStream: TMemoryStream; 
  VSBBmp: TBitMap; 
  VSBHöhe: integer;
const 
  PosBiHeight = 14 + 4 + 4;
begin
  Stream := nil;
  VSBStream := nil;
  Try
    Stream := TMemoryStream.Create;
    Stream.LoadFromFile(Dateiname);
    Stream.Position := 0;
    Stream.ReadData(AnzDS);
    If AnzDS <> BilderListe.Count
    then 
      raise EInvalidOperation.Create('Die Anzahl der Bilder stimmt nicht');
    VSBStream := TMemoryStream.Create;
    For BildNr := 0 to AnzDS - 1 do 
    begin
      VSBBmp := TBitMap.Create;
      try
        VSBBmp.LoadFromStream(Stream);
        VSBStream.Clear;
        VSBBmp.SaveToStream(VSBStream);
        VSBStream.Position := PosBiHeight;
        VSBStream.ReadData(VSBHöhe,SizeOf(VSBHöhe));
        VSBStream.Position := PosBiHeight;
        VSBStream.WriteData(-Abs(VSBHöhe));
        VSBStream.Position := 0;
        VSBBmp.LoadFromStream(VSBStream);
        Self[BildNr].VSB := VSBBmp;
        VSBBmp := nil;
      finally
        VSBBmp.Free;
      end;
    end;
  finally
    Stream.Free;
    VSBStream.Free;
  End;
end;

Wenn es jetzt rummst (sollte im Normalfall aber gar nicht rummsen), dann wieß man auch direkt warum :stupid:

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1326466)

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.

[Sir Rufo]

Eine VCL/FMX Anwendung wird bei einer nicht abgefangenen

Delphi-Quellcode:

Exception

NICHT angehalten.

Es fallen auch keine Kühe oder Häuser um, es wird lediglich eine MessageBox angezeigt, die den Message-Text der

Delphi-Quellcode:

Exception

anzeigt.

Eine

Delphi-Quellcode:

Exception

ist nicht böse sondern bewahrt mich davor unnötig viel Code zu schreiben oder irgendetwas auszuführen was gar nicht ausgeführt werden darf.

Zudem kann man gezielt auf eine

Delphi-Quellcode:

Exception

reagieren, wenn man dafür einen Plan B hat. Sonst lässt man die einfach ziehen und somit zur Anzeige bringen.

[Benmik]

Yess, Sir!
Auch ich finde Exceptions nicht böse! Ich finde sie gut! Sehr gut sogar! Honestly!
Ich bin nur der Meinung, das könne man besser machen. Programmiererfreundlicher. Nur als eine kleine Facette: Wie wäre es mit einem "Resume Next"?
Und nicht angehalten - na ja, es kommt eine MessageBox für den Anwender, und weiter geht es nicht, bis er was tut. Das ist sehr oft nicht das, was man will. Und die Routine wird sehr wohl verlassen, eine Schleife nicht weitergeführt. Geht in aller Regel auch nicht.
Wenn ich hier richtig mitlese, ist die endlose Kärrnerarbeit von zahllosen Try-Einfügungen auch bei Profis äußerst unbeliebt. Das kann man wirklich nicht besser machen?