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

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

[Sir Rufo]

Eine VCL/FMX Anwendung wird bei einer nicht abgefangenen Exception NICHT angehalten.

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

Eine 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 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?

[Benmik]

Darf ich fragen, warum in Sir Rufos Beispiel das

Delphi-Quellcode:

  Stream := nil;
  VSBStream := nil;

nötig ist? Der Compiler beanstandet, die Variablen würden nie benutzt.

[DeddyH]

Zitat von Benmik:

Darf ich fragen, warum in Sir Rufos Beispiel das

Delphi-Quellcode:

  Stream := nil;
  VSBStream := nil;

nötig ist? Der Compiler beanstandet, die Variablen würden nie benutzt.

Siehe http://forum.delphi-treff.de/index.p...-verschachteln

[BUG]

Zitat von Benmik:

Das kann man wirklich nicht besser machen?

Kann man z.B. mit RAII.
Am Ende ist Exception-sicheres Programmieren aber immer anstrengend. Nicht wegen den Exceptions, sondern weil das Problem (fehlertolerantes Programmieren) halt schwer ist.

[Blup]

Zitat von Benmik:

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?

Im Prinzip hat man nur die Möglichkeit konsequent Logik und linearen Programmablauf (eventuell auch Resourcenschutz) in einzelne Methoden aufzutrennen.

Delphi-Quellcode:

type
  TMyObject = class(TObject)
  protected
    procedure TuWas;
    procedure TuWasMitObject(AObject: TObject);
    procedure TuWasAnderes;
  public
    procedure TuIrgendWas;
  end;

implementation

procedure TMyObject.TuWas;
var
  lObject: TObject;
begin
  lObject := TObject.Create;
  try
    TuWasMitObject(lObject);  
  finally
    lObject.Free;
  end;
end;

procedure TMyObject.TuWasAnderes; 
begin
  {...}
end;

procedure TMyObject.TuIrgendWas; 
begin
  try
    TuWas;
  except
    TuWasAnderes;
  end;
end;

Bei Interfaces biete es sich an die Exceptionbehandlung in einem Decorator(Entwurfsmuster) zu implementieren.