Eigene Exceptions werden nicht immer behandelt

[Carsten1234]

Hallo zusammen,

zu den eigentlichen Exceptions möchte ich eine selbst erstellte Exception behandeln. Dazu habe ich folgendes deklariert:

Delphi-Quellcode:

TMyException = class(Exception)
  private
    FErrorType: integer; 
    FCommand  : integer; 
  public
     constructor Create(AMsg: string;
                        AErrorType: integer;
                        ACommand: integer); overload;
end;
(...)
constructor TMyException.Create(AMsg: string;
                                AErrorType: integer;
                                ACommand: integer);
begin
  inherited Create(AMsg);
  FErrorType:= AErrorType;
  FCommand:= ACommand;
end;

An besagter Stelle im Code, wo meine Exception ausgelöst werden soll, steht (ohne try..except Block):

Delphi-Quellcode:

raise TMyException.Create('Timeout', TIMEOUT, 10);

Im Hauptformular existiert folgende Definition:

Delphi-Quellcode:

procedure TMainForm.FormCreate(Sender: TObject);
begin
  Application.OnException:= AppException;
(...)
end;

Und weiter:

Delphi-Quellcode:

procedure TMainForm.AppException(Sender: TObject; E: Exception);
var MyException: TMyException;
begin
  if (E.ClassType = TMyException) then
  begin
    MyException:= nil;
    MyException:= E as TMyException;
    if (Assigned(MyException)) then
    begin
    // mach irgendwas hier
    end;
  end
  else
  begin
    MessageDlg('Es ist folgender Fehler aufgetreten:' +#10+#13+ E.Message + #10+#13 + 'Fehlertyp: '+ E.ClassName, mtError, [mbOk], 0)
  end;
end;

Starte ich mein Programm aus der IDE heraus und es wird meine Exception geworfen, so bekomme ich den Hinweis der IDE, dass meine Exception gefallen ist.
Aber: Oft, jedoch nicht immer (und für mich noch nicht nachvollziehbar), gelange ich gar nicht in die Exceptionbehandlung des Hauptformulars (Brechpunkt gesetzt) und es wird auch kein MessageDlg ausgegeben.

Frage: Wieso?

Danke für Tipps und Gruß, Carsten

[Muetze1]

Hi!

1. Warum nennst du deine Exception mit T am Anfang entgegen allen anderen Exceptions?
2. Warum versuchst du die Exception bei der letzten Bastion in der Applikation (Application.OnException) zu fangen und nicht lokal?
3. Warum vergleichst du ClassType mit der Exception-Klasse anstatt den Operator IS zu verwenden?
4. Warum weist du der lokalen Variable nil zu um dann nochmals einen anderen Werte (AS-Cast) zu zu weisen?
5. Warum die Prüfung auf Assigned() danach? Wenn AS fehlschlägt, dann wirft dieses eine Exception und somit wird dein Code dann eh nicht ausgeführt.

Gruss,
Muetze1

[Carsten1234]

Zitat:

Zitat von Muetze1

1. Warum nennst du deine Exception mit T am Anfang entgegen allen anderen Exceptions?
2. Warum versuchst du die Exception bei der letzten Bastion in der Applikation (Application.OnException) zu fangen und nicht lokal?
3. Warum vergleichst du ClassType mit der Exception-Klasse anstatt den Operator IS zu verwenden?
4. Warum weist du der lokalen Variable nil zu um dann nochmals einen anderen Werte (AS-Cast) zu zu weisen?
5. Warum die Prüfung auf Assigned() danach? Wenn AS fehlschlägt, dann wirft dieses eine Exception und somit wird dein Code dann eh nicht ausgeführt.

1. Ich kann sie auch ohne T am Anfang benamsen, ist aber nur nebensächlich.
2. Die Unit, in der meine Exception geworfen wird, ist eine reine Kommunikationsunit (ohne Formular). Die eigentliche Textausgabe soll im Hauptformular erfolgen, u.a. auch deshalb, weil meine Anwendung mehrsprachig werden soll.
3. 4. 5. Ist änderbar, allerdings hilft mir das nicht bei der Lösung meines Problems weiter, da ich ja nicht mal in die AppException komme.

Gruß, Carsten

[sirius]

Wer ruft denn eine Funktion in deiner Unit auf, in welcher auch die Exception kommen kann?

[Muetze1]

Wenn du in einer "Communications Unit" diese Exception wirfst, dann wird dort wohl eher WinAPI und direkte DLL Calls verwendet und somit liegt dort keine VCL Call-Frame drum - und noch seltener die des Application Objektes. Wenn du keine Funktion dieser "Coomunications Unit" von einem Formular oder sonstigem aufrufst, geschehen die Aufrufe nicht im Context der TApplication Instanz und somit auch nicht deren Message Handler. Die logische Folge ist somit, dass das Application Objekte keine der Exceptions fangen kann, da diese nicht der ursprüngliche Caller geschweige denn ein eigenes Context-Objekt ist.

[mjustin]

Zitat:

Zitat von Muetze1

Die logische Folge ist somit, dass das Application Objekte keine der Exceptions fangen kann, da diese nicht der ursprüngliche Caller geschweige denn ein eigenes Context-Objekt ist.

Genau. Man hat also zwei Möglichkeiten:

einfach: an der richtigen Stelle halt ein try ... except einbauen, um alle Exceptions aus den Untiefen des Programms aufzufangen

con tutto: madExcept oder etas ähnliches verwenden - da werden alle im uns bekannten Universum möglichen Exceptions umgeleitet (wenn ich den Sourcecode richtig lese)

Cheers,