Hallo Delphifreunde!

Ich beziehe mich auf jene Diskussion, in der mir gut geholfen wurde (danke nochmal dafür!).

Nunmehr lagere ich die zeitintensiven Berechnungen sukkzessiv in externe Threads aus, es klappt soweit auch ganz gut. Der Zugriff auf einige VCL-Elemente bzw. -Funktionen ist teilweise erschwert, es muß dann mit synchronize gearbeitet werden, aber die Vorteile am fertigen Programm sind naütrlich erheblich.

Doch jetzt wird es schwieriger. Eine bestimmte Berechnung erlaubt nicht alle Eingaben (das ist ja in der Mathematik sehr oft so), und derart ungültige Berechnungen werden mit try abgefangen (wohl der einfachste Weg, anstatt die Eingabewerte "mühsam" und ggf. sogar einzeln auf Konsistenz zu prüfen):

markieren

Delphi-Quellcode:

try
//Versuch der Berechnung
except showmessage('Fehler')
end;

funktionierte im VCL-Thread tadellos, sodaß das Programm auch bei ungültigen Eingaben eine Fehlermeldung ausgibt und danach problemlos weiterläuft, anstatt abzustürzen.

Im Extra-Rechenthread jedoch funktioniert das

zusammenfalten · markieren

Delphi-Quellcode:

procedure Fehlermeldung;
begin
showmessage('Fehler')
end;

.
.
try
//Versuch der Berechnung
except synchronizie(Fehlermeldung)
end;

nur insoweit, als daß die Fehlermeldung zwar auch kommt, wenn die Bedingungen dafür gegeben sind, jedoch danach das Programm dennoch mit einer Fehlermeldung ("Exception") abstürzt.

Kann man dem try-except-block die volle Funktionalität wie im VCL-Thread verpassen, also diesen Absturz irgendwie vermeiden?

Danke im voraus und Gruß

Delphi-Laie

Zitat von Delphi-Laie:

nur insoweit, als daß die Fehlermeldung zwar auch kommt, wenn die Bedingungen dafür gegeben sind, jedoch danach das Programm dennoch mit einer Fehlermeldung ("Exception") abstürzt.

Welche Exception kommt denn genau?

Zitat von Uwe Raabe:

Zitat von Delphi-Laie:

nur insoweit, als daß die Fehlermeldung zwar auch kommt, wenn die Bedingungen dafür gegeben sind, jedoch danach das Programm dennoch mit einer Fehlermeldung ("Exception") abstürzt.

Welche Exception kommt denn genau?

Siehe Anhang.

Sie kommt nach meiner selbstprogrammierten Fehlermeldung, und danach ist mit dem Programm Ende.

Wie gesagt, als alles im VCL-Thread lief, lief es wie gewünscht.

Die Excepion hat eine andere Ursache. Überprüfe mal, ob die im Fehlerfall nicht doch irgendwelche Variablen verwendest, die dann noch nicht oder nicht mehr da sind. Immerhin wird der Code im Thread nicht vollständig durchlaufen, sondern mittendrin durch die Exception abgebrochen.

Wenn du mehr wissen willst, musst du mehr Code liefern.

Zitat von Uwe Raabe:

Die Excepion hat eine andere Ursache.

Eine andere Ursache als was?

Zitat von Uwe Raabe:

Überprüfe mal, ob die im Fehlerfall nicht doch irgendwelche Variablen verwendest, die dann noch nicht oder nicht mehr da sind.

Mit Sicherheit kann etwas nicht (richtig) konvertiert werden, das war mir gleich klar, aber dafür ist try..except schließlich da und funktionerte doch vorher auch.

Zitat von Uwe Raabe:

Immerhin wird der Code im Thread nicht vollständig durchlaufen, sondern mittendrin durch die Exception abgebrochen.

Ja, aber genau dafür, um so etwas abzufangen, ist schließlich doch try..except da (jetzt wiederhole ich mich allmählich)?! Wie kann ein und derselbe Code in einem Thread eine exception auslösen, im anderen Code, der im VCL-Thread läuft, die exception abgefangen werden? Leuchtet mir nicht ein.

Zitat von Uwe Raabe:

Wenn du mehr wissen willst, musst du mehr Code liefern.

Das ist leider nicht so einfach, denn es spielen mehrere Routinen und Deklarationen aus mehreren Units mit. Aber wenigstens scheint sich auch Nicht-VCL-Thread-Code im Quelltext via Debugger schrittweise nachverfolgen zu lassen.

Danke an Dich erstmal für Dein Bemühen!

So, ich bin ein Stück weiter.

Schuld ist nicht irgendeine der externe Berechnungsfunktionen aus einer externen Unit, sondern - als Argument dafür - eine schnöde Typkonvertierung (prinzipieller Quellcode):

markieren

Delphi-Quellcode:

try
strtoint([String(variable)])
except

, wobei der String, als Integerzahl gedacht, größer als der größtmögliche Wert der Integervariablen ist (der String könnte genausogut ungültige Zeichen enthalten, gerade ausprobiert).

Außerhalb des VCL-Threads funktioniert try..except offenbar nur eingeschränkt: Except wird zwar aufgerufen, die Exception jedoch nicht abgefangen.

Fehler gefunden: Es lag am Aufruf einer anderen Prozedur, die immer, also auch nach dem try..except, aufgerufen wurde. (Ermitteln der Systemzeit, jedenfalls ist der zentrale Befehl in jener Prozedur QueryPerformanceCounter. Das passiert, um die Rechendauer zu ermitteln.)

Mit dem nur noch optionalem Aufruf der Prozedur (nicht, wenn except aufgerufen wird, dann wird eine boolesche Variable auf false gesetzt, was den späteren Aufruf verhindert) ist der Programmabbruch vermeidbar.

Dieses Programmverhalten leuchtet mir nicht ein und stellte im VCL-Thread auch kein Problem dar.

Danke noch einmal, Uwe!

Ergänzung: Ganz so sauber, wie dargestellt, lief es auch im VCL-Thread doch nicht ab: Nach der programmierten Fehlermeldung kam auch noch eine exception hinterher, aber das Programm stürzte nicht ab (indem es aus dem Speicher verschwand), sondern ließ sich nach dem "Wegklicken" letzter weiterbenutzen.

Dann verhält sich aber nicht try..except anders, sondern der Fehler in deinem Code hat in einem anderen Thread schwerwiegendere Auswirkungen. Er sollte jedenfalls in beiden gefixed werden

Ich bin auch kein großer Fan von ShowMessage in Threads. Ich mir angewöhnt um die Execute-Methode immer komplett(!) noch einen try..except zu bauen, in dessen execpt-Teil in ein Logfile oder eine Tabelle protokolliert wird. Zusätzlich zu den in dieser aufgerufenen Methoden, die ggf. selbst auch loggen um Fehler genauer eingrenzen zu können. Gerade wenn mehrere Threads rege miteinander interagieren vermeidet man so ggf. falsche Folgefehler, die dadurch kommen, dass andere Threads auf den dann angehaltenen warten während er synced die Meldung anzeigt.

In einem Thread ShowMessage aufzurufen ist auch nicht so clever, da es ein VCL Dialog ist und damit nicht threadsafe. Nimm für so etwas mal die eine Messagebox von Windows. aber ich würde so wie so, die Exceptions im Thread nur auslösen und im Main Thread behandeln. Dann ist der Code auch besser wieder verwendbar.

Wie würde man das machen Luckie? Ich kann ja um einen Thread im VCL-Thread kein try..except machen, da sie ja nicht parallel laufen. Ich behelfe mir hier oft auch mit eigenen Messages, die ich meinem Mainform poste, wenn ich nicht (wie oben beschrieben) loggen will / kann. Denen klebe ich dann meist einen Pointer zu einem Record an, der ggf. weitere Infos zum Fehler enthält (z.B. den Fehlertext), was durch das Gecaste und New() im Thread aber Dispose() im Mainthread immer etwas "unsafe" und gefummelt wirkt.

Alternativ ließe sich ja auch ein Error-Eventhandler in der Threadklasse synchronized aufrufen, was etwas hübscher ins OO-Konzept passt. Aber hier ist man dann auch wieder darauf angewiesen, dass der Handler im Mainthread nicht ggf. zu eben solch einer Blockade führt wie oben beschrieben.