Das try...finally ist weniger der Exceptions wegen (die erwarte ich im try-Block nicht), sondern dazu, dass ich im try-Block ein exit ausführen kann, wenn ich weiter innen mit dem Aufstellen der Antwort fertig bin. Kann man auch anders lösen, muss man aber nicht.
Im übrigen ist das ein Beispiel-Code, um zu zeigen, wo das Sleep platziert ist, und nicht etwa der Code im Endzustand. Da müsste auch noch ein try...except, um den Block, der den ContentText behandelt herum, um konsistent zu sein. Aber der beschriebene Fehler tritt in erster Linie im ContentStream-Block auf.
Und ich habe nicht gesagt, dass ich das gleiche Frame jedesmal in JPEG umwandle. Aber wenn alle Clients während der 2-3 Sekunden, in denen die Umwandlung zum ersten und einzigen Mal stattfindet, anfragen, dann müssen sie halt auch alle warten, bis die erste Erstellung vorbei ist. Und dieses Warten ist, wie gesagt, so gewollt. Danach wird bis zum Zwischenspeichern eines anderen Frames aus einem Cache, der die JPEG-Variante enthält, gelesen.
Und nochmal: ich habe hier das recht _allgemeine_ Problem, dass bei einer langen Antwortberechnung (egal wie die jetzt im Detail aussieht, ob ContentText oder ContentStream benutzt wird etc.) das Programm _kommentarlos_ abstürzt.
Ich bin dankbar für eure Mühen.
Aber ich bin kein Anfänger, dem man die Grundlagen des
Exception-Handlings erklären muss, NUR weil in dem unfertigen Beispiel-Stück vielleicht das eine oder andere Detail noch nicht ganz perfekt aussieht. Das Problem liegt hier an einer anderen Stelle, soweit bin ich schon gekommen. Mein Problem ist, dass ich den detaillierten Aufbau des
Indy HTTP-Servers nicht kenne und mir das Programm mangels Fehlermeldung auch keinerlei Hinweis darauf gibt, wo das Problem sein könnte (trotz try...except-Block um die betreffende Stelle).
Und sollte es da irgendwo eine Zugriffsverletzung geben, dann weiß ich nicht, wie das Programm auf derartige Exceptions reagiert. Da habe ich schon unterschiedlichste Erfahrungen gemacht, je nach dem, ob solche Exceptions in eingebundenen Laufzeitbibliotheken (statisch oder dynamisch eingebunden) oder im Hauptprogramm, im Main-Thread oder einem Hintergrund-Thread auftreten. Die Bandbreite reicht von
Exception mit Fehlermeldung, über Fehlermeldungen mit Programmabsturz, Einfrieren des Programms bis hin zum kommentarlosen verschwinden. Und das alles auch, wenn der entsprechende Teil mit einem try...except-Block geschützt war. Evtl. räumt ja der
Indy HTTP-Server irgendwo nach einem Timeout was auf, was noch nicht aufgeräumt werden sollte.
Ich werde jetzt mal einen try...except-Block um das ganze Programm machen, in der Hoffnung, irgendwas zu finden. Da es sich allerdings um einen Server handelt und der Fehler beim Senden der Antwort liegt, weiß ich nicht, ob der try...except-Block dann den richtigen Thread "umfasst".