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

[himitsu]

Wenn du RAISE erneut auslöst, dann empfehle ich per AT die ursprüngliche Fehlerposition mitzugeben, vor allem wenn RAISE in einer anderen Methode ausgeführt wird,
denn beim Debuggen macht es keinen Spaß, wenn man nicht mehr sieht wo der Fehler eigentlich war, und auch beim Error-Logging wäre es gut.

Statt nur raise; ein raise Exception.Create(E.Message) at ExceptAddr; ,

aber natürlich ist es Blöd, wenn die Exceptionklasse verloren geht, da somit anschließend E IS und auch on E: AndererExceptionTyp do nicht mehr möglich sind.

Delphi-Quellcode:

raise (E.ClassType).Create(E.Message) at ExceptAddr;

raise Exception.Create(Exception(ExceptObject).Message) at ExceptAddr;

...

Natürlich gibt es noch weitere Infos, welche verloren gehen, wie z.B. E.ErrorCode bei Windows.Exceptions.

Oder ihr spielt etwas mit InnerExceptions/OuterExceptions rum.






Das Selbe gilt übrigens auch, wenn man die Exception-Erzeugung in eine Fuunktion verlagert, denn wen interessiert die Stelle wo das RAISE ausgelöst wurde, wo ja eigentlich die Stelle wichtig ist, wo MyCreateException aufgerufen wurde. (PS: TList und Co. machen sowas, für ihre Exceptions)

Delphi-Quellcode:

procedure MyCreateException(S: string);
begin
  WriteErrorLog(S);
  raise Exception.Create(S) at ReturnAddr;
end;

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