TRestRequest beim Beenden abbrechen

[TurboMagic]

Hallo,

angenommen ich habe in Delphi 11.1 einen TRestRequest mittels Execute
in einem TTask gestartet. Das ist ein Post Request an einen entferten Server
der mitunter etwas dauert.

Wenn nun jemand das Programm (bei dessen Start dieser Request abgesetzt wird)
schließt, bevor der Request abgearbeitet ist, knallt es (laut Debugger genau
in der Zeile nach dem Execute Aufruf).

Wie kann ich so einen Request richtig abbrechen in der Situation?
Ich hab's schon mit Cancel versucht, aber das scheint nicht zu helfen.

Die TRestRequest Komponente liegt auf einem Datenmodul, wird aber von
anderen Klassen benutzt, wobei eine ein Interface definiert welches benutzt
wird.

Die Klasse, die dieses Interface benutzt wird beim beenden freigegeben.
Und nein: ich greife nicht in die Referenzzählung ein.

Grüße
TurboMagic

[Uwe Raabe]

Kannst du das auf ein minimales Beispiel runterbrechen?

[himitsu]

Erstmal würde ich empfehlen diese Komponente(n) in dem Task/Thread zu erstellen,
dort, wo sie dann verwendet wird, anstatt diese VCL-Komponente threadübergreifend zu verwenden.


Aber warum überhaupt ein Task (RESTRequest.Execute?)
anstatt RESTRequest.ExecuteAsync + OnAfterExecute?




PS, das passende Handle gefunden, könnte man auch in dieser Richtung mal weiter experimentieren:
https://docs.microsoft.com/en-us/win...i-o-operations

[TurboMagic]

Danke für den Async Tipp! Werde ich mir mal anschauen.
Dieses REST Zeugs ist halt noch neu für mich...

Was wäre dann der Standardweg das abzubrechen?
TRESTRequest.Cancel?

[TurboMagic]

So, habe das jetzt auf ExecuteAsync umgestellt und die Aufrufen werden durch
das Entfernen des bisher benutzten TTasks viel schneller. Wow!

Dass ich den Synchronized Parameter auf True stellen sollte ist mir klar,
da meist irgendwann im Verlauf der Antwortverarbeitung was auf dem GUI ausgegeben wird.
Aber: es stellt sich mir jetzt noch die Frage wie der 3. Parameter AFreeThread
am besten zu setzen ist: true oder false?

Und der 4. Parameter ist in der Hilfe gar nicht beschrieben. Kann mir den mal
jemand erklären? Ich habe zwar einen Verdacht, aber eigentlich hatte ich bisher schon
anderweitig ein Fehlerbehandlungsevent eingebaut...

[himitsu]

eigentlich ganz einfach ... PS: notfalls mal in den Code gucken :)


ACompletionHandler: TCompletionHandler = nil
ASynchronized: boolean = True
AFreeThread: boolean = True
ACompletionHandlerWithError: TCompletionHandlerWithError = nil
Result: TRESTExecutionThread

alle Parameter kann man ignorieren, wenn man sie nicht braucht (wenn nur OnAfterExecute, dann kann alles leer bleiben)

ACompletionHandler = anonyme Ereignis-Methode alternativ/zuzüglich zum OnAfterExecute
ACompletionHandlerWithError (aka AErrorHandler) = ähnlich wie Erstes ... ohne=wenn erfolgreich / mit=wenn Abfrage nicht erfolgreich
ASynchronized = CompletionHandler mit oder ohne Error sind synchronisiert (nur die beiden Methoden, nicht das Event OnAfterExecute)
AFreeThread = Auto-Free des internen TThread ... oder du speicherst dir das Result und gibst es am Ende selbst frei (selbst: NIEMALS innerhalb der Ereignismethoden)
Request.SynchronizedEvents = das "Synchronized" für OnAfterExecute
Request.OnHTTPProtocolError = ähnlich ACompletionHandlerWithError

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1508797)

Aber: es stellt sich mir jetzt noch die Frage wie der 3. Parameter AFreeThread
am besten zu setzen ist: true oder false?

Wenn du den auf False setzt, kannst du den Rückgabewert von ExecuteAsync verwenden um das Cancel aufzurufen, falls du den Request selbst nicht mehr zur Hand hast.

Zitat:

Zitat von TurboMagic (Beitrag 1508797)

Und der 4. Parameter ist in der Hilfe gar nicht beschrieben. Kann mir den mal
jemand erklären?

Der ACompletionHandlerWithError wird aufgerufen, wenn im Execute eine unbehandelte Exception auftritt (der Parameter enthält dann das Exception Object). Das gibt einmal die Möglichkeit einer freundlichen Meldung, aber auch die letzte Gelegenheit irgendwelche Dinge aufzuräumen, die eigentlich im ACompletionHandler gemacht werden, aber der wird bei einer Exception möglicherweise nicht mehr aufgerufen (außer die Exception kommt genau da her).