raise Exception.Create() feuert ApplicationEvents nicht aus TTask an

[DieDolly]

Ich hab das gerade noch einmal getestet.
Ich werde TTask in Zukunft definitiv meiden.

In meinem TTask habe ich mehrere Zeilen Code und auch zum Test ein try-except.

Wenn ich absichtlich einen Fehler erzeuge indem ich eine Internetseite mit Get aufrufe die es nicht gibt, springt Delphi niemals in den except-Teil der sofort nach IdHTTP1.Get() folgt.

[himitsu]

Das liegt dann aber nicht an TTask.

Es gibt einige Komponenten, wie teilweise auch in den Indy, welche selber drinen ein TryExept haben, interne Fehler abfangen
an eigene Exception-Ereignisse weiterleiten und eventuell anschließend nicht "eventuell" neu auslösen.
Bzw. die Fehler werden in Property/Funktionen gespeichert/bereitgestellt und die Methode gibt z.B. nur False zurück. (so wie man es oft von der WinAPI mit seinem GetLastError kennt)


Aber sowas kann man da oftmals irgendwo einstellen, wie es sich verhalten soll.

[DieDolly]

Dann wurde kürzlich irgendwas geändert.

Dieses beispiel funktioniert in einem TTask nicht.

Delphi-Quellcode:

try
 idhttp1 ... get(nicht existierende url);
except
 mache irgendwas, showmessage oder oder
end;

[ScharfeMietze]

Zitat von DieDolly:

Ich hab das gerade noch einmal getestet.
Ich werde TTask in Zukunft definitiv meiden.

In meinem TTask habe ich mehrere Zeilen Code und auch zum Test ein try-except.

Wenn ich absichtlich einen Fehler erzeuge indem ich eine Internetseite mit Get aufrufe die es nicht gibt, springt Delphi niemals in den except-Teil der sofort nach IdHTTP1.Get() folgt.

Delphi-Quellcode:

procedure TTGMBot.btn14Click(Sender: TObject);
begin
  TTask.run(procedure()
  begin
  try
    idhtp1.Get('http://www.delphibtzujtzujasics.co.uk/RTL.asp?Name=raise');
  except on E: Exception do
    begin

    end;
  end;
  end)
end;

geht bei mir. dort kann ich die e.message nun verarbeiten,speichern an ein property senden, was auch immer. eventuell solltest du noch ein antifreeze auf die form ziehen.

[Schokohase]

Zitat von ScharfeMietze:

eventuell solltest du noch ein antifreeze auf die form ziehen.

Da hier soviel hilft wie Schlangenöl ins WLAN-Kabel einzumassieren.

Denn

1. Der Aufruf erfolgt in einem anderen Thread also wird der UI-Thread gar nicht blockiert. AntiFreeze ruft einfach nur Application.ProcessMessages auf, allerdings auch nur bei Aufrufen innerhalb des UI-Threads, also in diesem Falle gar nicht.
2. Während der Auflösung des Namens in eine IP-Adresse wirkt AntiFreeze gar nicht, also in diesem Falle gar nicht (selbst wenn wir im UI-Thread wären). AntiFreeze hat nur Auswirkungen während der Datenübertragung zwischen den beiden Systemen, sonst nicht.

Die Auflösung des Names kann auch mal etwas länger dauern (ca. 10 Sekunden). Wer dann ungeduldig ist, der könnte in die Versuchung kommen, dass dort der Exception-Block nie angesprungen wird (weil man die Anwendung nach 8 Sekunden schon wieder abgewürgt hat, weil ja nichts passiert ist).