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

[DieDolly]

Ich habe eben festgestellt, dass ApplicationEvents nicht mehr feuert. Warum weiß ich nicht. Änderungen gab es keine.

Auf einer Form habe ich TApplicationEvents und das Event OnException ist zugewiesen. Da drin ist eine Showmessage(E.Message).
Wenn ich irgendwo im Programm raise Exception.Create('TEST EXCEPTION'); ausführe sehe ich die Showmessage in OnException leider nie.

Woran kann das liegen?

[Sherlock]

Zunächst, bau ein neues Projekt, in dem Du genau diese beiden Dinge nochmal tust. Prüfe ob es geht. Wenn ja, hast Du doch etwas geändert, und das läßt sich ja in der Versionsverwaltung verifizieren. Wenn nein, bin ich bereits mit meinem Latein am Ende...

Sherlock

[DieDolly]

Die Versionsverwaltung ist unauffällig.

In einem neuen Projekt passiert das nicht. Mir ist aber aufgefallen, dass Exceptions nur in einem TTask nicht funktionieren.
Das ist mehr als seltsam. Außerhalb is t alles OK.

Das hier auf das MainForm eines neuen Projekts in einen Button oder oder oder.
Exception 2 geht bis ans Ende durch (bis zum AplicationEventsOnException). Exception 1 verhungert.

Delphi-Quellcode:

 TTask.Run(
  procedure
  begin
   raise Exception.Create('TEST EXCEPTION 1');
  end);

  raise Exception.Create('TEST EXCEPTION 2');

[hoika]

Hallo,
hilft Dir das hier?

http://robstechcorner.blogspot.com/2...anagement.html

[TiGü]

Zitat:

Zitat von DieDolly (Beitrag 1415491)

In einem neuen Projekt passiert das nicht. Mir ist aber aufgefallen, dass Exceptions nur in einem TTask nicht funktionieren.

Beantworte folgende Frage:
Was passiert mit Exceptions in einem klassischen TThread, die innerhalb der TThread.Execute-Methode auftreten?

[DieDolly]

Du möchtest sicher darauf hinaus, dass man das in den Mainthread synchronisieren muss.

Aber ich glaube die Lösung mit TThread.Synchronize(TThread.CurrentThread ... funktioniert nur bei System-Exceptions. Also raise E; und nicht raise Exception.Create();.

[TiGü]

Mach mal aus Glauben ein Wissen.

[DieDolly]

Ich habe meinen Glauben gerade mit diesem Code geprüft. Die Exception geht trotzdem nicht durch.
Der obere mit SwapNames. Das steht bei mir im TTask und im except rufe ich raise E; auf.

http://www.delphibasics.co.uk/RTL.asp?Name=raise

[TiGü]

Delphi-Quellcode:

program Project5;

{$APPTYPE CONSOLE}

{$R *.res}


uses
  System.SysUtils,
  Winapi.Windows,
  System.Classes,
  System.Threading;

type
  TMyThread = class(TThread)

  protected
    procedure Execute; override;
  end;

  { TMyThread }

procedure TMyThread.Execute;
var
  I: Integer;
begin
  inherited;
  while I < 1000 do
  begin
    if I = 900 then
    begin
      raise Exception.Create('Error Message');
    end;
    Inc(I);
  end;
end;

var
  MyThread: TMyThread;
  MyTask: ITask;

begin
  try
    MyThread := TMyThread.Create;

    MyThread.WaitFor;

    if Assigned(MyThread.FatalException) then
    begin
      Writeln(Exception(MyThread.FatalException).ClassName, ': ', Exception(MyThread.FatalException).Message);
    end;

    MyThread.Free;



    MyTask := TTask.Run(
        procedure
      var
        I: Integer;
      begin
        I := 0;

        while I < 1000 do
        begin
          if I = 900 then
          begin
            raise Exception.Create('Error Message');
          end;
          Inc(I);
        end;
      end).Start;

    // ruft intern TTask.CheckFault auf
    MyTask.Wait();

    Readln;
  except
    on E: EAggregateException do
    begin
      Writeln(E.ClassName, ': ', E.Message);

      if (E is EAggregateException) and Assigned(EAggregateException(E).InnerExceptions[0]) then
      begin
        Writeln(EAggregateException(E).InnerExceptions[0].ClassName, ': ', EAggregateException(E).InnerExceptions[0].Message);
      end;

      Readln;
    end;
  end;

end.

[DieDolly]

Das ist nicht die beste Lösung. Da lasse ich TTask am besten weg und überdenke alles.
Wenn ich Wait aufrufe und eh auf den Task warten muss, dann brauche ich keinen Task.

Ich überdenke alles noch einmal und baue das in einen traditionellen TThread um.

[TiGü]

Ich kann dir sowas noch anbieten:

Delphi-Quellcode:

unit Unit4;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs,
  System.Threading, Vcl.StdCtrls;

type
  TForm4 = class(TForm)
    Memo1: TMemo;
    procedure Memo1Click(Sender: TObject);
  private
    { Private declarations }
  public
    procedure DoIt;
    procedure LogText(const AText: string);
  end;

var
  Form4: TForm4;

implementation

{$R *.dfm}


procedure TForm4.DoIt;
var
  MyTask: ITask;
  MyProc, DoMyProc, HandleException: TProc;
begin
  MyProc := procedure
    var
      I: Integer;
    begin
      I := 0;

      while I < 1000 do
      begin
        if I = 900 then
        begin
          raise Exception.Create('Error Message: ' + TThread.Current.ThreadID.ToHexString);
        end;
        Inc(I);
      end;
    end;

  DoMyProc := procedure
    begin
      try
        MyProc;
      except
        on E: Exception do
        begin
          TThread.Synchronize(nil,
              procedure
            begin
              LogText(E.ClassName + ': ' + E.Message)
            end);
        end;
      end;
    end;

  MyTask := TTask.Run(DoMyProc);
  MyTask.Start;
end;

procedure TForm4.LogText(const AText: string);
begin
  Memo1.Lines.Add(AText);
end;

procedure TForm4.Memo1Click(Sender: TObject);
begin
  DoIt;
end;

end.

[ScharfeMietze]

Du könntest eine property befeuern und diese reagieren lassen ;)
Gruß

[DieDolly]

Das verstehe ich jetzt nicht.

[ScharfeMietze]

Du kannst doch eine Property im HauptProgramm ansprechen und diese reagieren lassen im Setter

Delphi-Quellcode:

  TTask.Run(
  procedure
  begin
    testExeption:= 'TEST EXCEPTION 1';
  end);

Delphi-Quellcode:

 property testExeption: string read FtestExeption write set_testExeption;

Delphi-Quellcode:

procedure TTGMBot.set_testExeption(const Value: string);
begin
  FtestExeption := Value;
  ShowMessage(value);
end;

Das ist nun ziemlich vereinfacht. aber hier kannst du neue aktionen anstoßen, je nachdem wie du den Fehler behandeln willst...

[DieDolly]

Im Prinzip also statt raise Exception.Create(); im TTask eine eigene Procedur im TTask aufrufen, die dann intern raise Exception.Create(); aufruft?

[ScharfeMietze]

Wenn du "nur" eine Meldung ausgeben willst als Fehlerbehandlung würde ich eher eine Messagebox verwenden...

[DieDolly]

Möchte eigentlich nur in eine Datei schreiben.
Genau das passiert aus dem TTask ja leider nicht. Ich versuche es morgen mal mit deiner Lösung, eine Procedure aufzurufen die dann raise aufruft oder ich schreibe direkt von da aus in die Datei.

[himitsu]

Nochmal zur Info:

Application.OnException wird ausschließlich durch Exceptions innerhalb der VCL und im Mainthread aufgerufen,
denn die VCL hat ein Try-Except um die Messagebehandlung und da drin "manuell" den OnException-Aufruf.

Deswegen ist seit einer Weile auch in "neuen" Konsolenanwendungen standardmäßig ein Try-Except vorhanden.

ACHTUNG: Wenn Exceptions nicht abgefangen werden und unbehandelt bis zum Windows durchrauschen, dann beendet Windows sofort die komplette Anwendung.


Aus diesem Grund haben auch die VCL, TThread und der neue TTask ein Try-Except eingebaut, welches Exceptions abfängt, damit im Fehlerfall nur diese Message, bzw. der Thread/Task abraucht, aber nicht gleich die ganze Anwendung.

ABER, "leider" werden diese Fehler nicht automatisch in den Hauptthread synchronisiert und da angezeigt.
Das ginge auch nicht immer automatisch, da es eventuell zu einem Deadlock kommen könnte, wenn dadurch die Bearbeitung dieses oder des Hauptthreads blockiert würde.

Bei TThread mußt DU dich in OnTerminate oder DoTerminate hängen und den Wert von FatalException prüfen.

Delphi-Quellcode:

if Assigned(FatalException) then
  Synchronize(...);  // Exception(FatalException) z.B. "synchronisiert" an Application.HandleException oder an Application.ShowException

Bei TTask weiß ich jetzt nicht, wo es dort sowas wie das FatalException/OnTerminate gibt.


Aber in beiden Fällen würde ich zu einer manuellen Behandlung raten, also ein eigenes Try-Except um deinen kompletten Code im Task/Thread.

Denn wenn du das nicht abfängst, dann verschwinden Exceptions innerhalb von Threads ungehört im Nirvana.
Und ja, ich finde dieses Standardverhalten auch schwachsinnig,
außerdem verstehe ich nicht, warum es seit Jahrzehnten nicht ebenfalls für Thread-Exceptions ein "zentrales" Event existiert, so wie dieses Application.OnException für VCL/FMX.

Delphi-Quellcode:

//lokales var E: Exception;
try

except
  E := Exception(AcquireExceptionObject);
  E.Message := Format('ThreadID %d: %s', [{TThread.Current.ThreadID}GetCurrentThreadId, E.Message]);
  TThread.ForceQueue(nil, procedure
    begin
      Application.HandleException(E);
    end);
end;

Problem bei TThread: Die nehmen auch via AcquireExceptionObject die Exception aus der Behandlung, aber bieten es nicht den Besitz zu übernehmen, weswegen innerhalb von OnTerminate kein Queue/ForceQueue verwenden kann, außer man klont vorher aufwändig diese Exception, welche TThread kurz nach OnTerminate immer sofort freigibt.

[DieDolly]

Wäre es eine clevere Lösung den Zwischenschritt raise einfach wegzulassen?
Stattdessen würde ich eine neue Procedur einführen, die in meine Fehlerdatei schreibt. Und überall wo ich aktuell raise aufrufe, rufe ich dann diese Prozedur auf.

Dann sollte ich theoretisch doch alle Limitierungen los sein?

Statt

Delphi-Quellcode:

raise Exception.Create('123');

also

Delphi-Quellcode:

SchreibeInDatei('123');

Vielleicht könnte man in SchreibeInDatei() ja auch prüfen, ob man gerade im Mainthread ist oder nicht?

[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

Delphi-Quellcode:

raise;

ein

Delphi-Quellcode:

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

,

aber natürlich ist es Blöd, wenn die Exceptionklasse verloren geht, da somit anschließend

Delphi-Quellcode:

E IS

und auch

Delphi-Quellcode:

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:

Zitat von DieDolly (Beitrag 1415675)

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:

Zitat von ScharfeMietze (Beitrag 1415678)

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
   Delphi-Quellcode:

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