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

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

 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 raise Exception.Create('123'); also 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 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;