Exceptions aus DLL

[MStoll]

Hallo,

mal nebenbei eine Frage zur Weitergabe von Exceptions aus DLLs an das aufrufende Programm.

Code in DLL:

Delphi-Quellcode:

procedure FunktionAusDLL();
begin
     raise exception.create('Test-Exception!');
end;

Code in der Anwendung:
Fall 1:

Delphi-Quellcode:

try
   FunktionAusDLL();
except
   on e: exception do
      MessageDlg(e.message, mtError, [mbCancel], 0);
end;

Fall 2:

Delphi-Quellcode:

FunktionAusDLL();

Im ersten Fall wird ganz normal die Fehlermeldung ("Test-Exception!") angezeigt.
Im 2. Fall sollte diegleiche Meldung doch als MessageBox über Application.OnException angezeigt werden (sofern man die OnException-Methode nicht durch eine eigene ersetzt hat), oder?
Aber irgendwie kommt dann immer nur ein allgemeiner Fehler (z.B. AV-Error etc.)

Deswegen habe ich bereits ein try..except-Konstrukt in der Art von Fall 1 benutzt mit einem zusätzl. exit im except-Teil, was ja eigentlich nicht sein sollte, da imho die globale Exception-Routine den gleichen Effekt haben sollte.

Weiß einer von euch, warum das so ist?

Gruß
Michael

P.S. Benutze den NexusDB Memory Manager.

[Olli]

Die RTTI in einer DLL und einem Programm müssen sich nicht entsprechen und tun es meist auch nicht. Daher - und weil Exceptions ein teils OS-unterstütztes Sprachkonstrukt sind - kann man diese "Objekte" nicht über diese Grenze hinweg schicken. Es sollte aber möglich sein, wenn du mit Packages arbeitest ...

[QuickAndDirty]

Ich hab das über einen Record gelöst. Ich gebe
EDBENGINEERROR Exceptions über einen Record der als Var parameter
an die DLL Funktion übergeben wird weiter.
Nach der DLL Funktion wird das Record in der Anwendung einer Funktion
Übergeben die es verarbeitet.
Der Record hat ein occured flag ist das gesetzt baut
die Funktion ne Exception und raised sie auch.


Alle anderen Funktionen geben bei mir einfach nur einen Errorcode wieder,
0 heist dann alles gut .

[rochus]

Hi,

Ich mach das immer so:

Jede Funktion hat einen Rückgabewert, der widerspiegelt, ob alles okay verlaufen ist oder nicht (z.B. S_OK). Wird nicht S_OK zurückgegeben, sollte es eine Möglichkeit geben, an die entsprechende Exception zu kommen - manchmal brauchst du die ja z.B. gar nicht, warum sollte sie dann auch weitergeschleift werden. Dazu gibts bei mir immer eine Funktion die wie die WinAPI Methode GetLastOSError arbeitet, nur dass sie eben einen anderen Namen und andere Returncodes hat. Als Rückgabewert kannst du dann z.B. ein Record oder ein Interface definieren o.ä. Das gibt dir dann auch die möglichkeit, eine Funktion zu basteln, in der die letzten n Exceptions angezeigt werden. Du speicherst also z.B. die Exceptions in einer Queue o.ä. Das ist dann hilfreich, wenn du wie gesagt eine Methode hast, die z.B. ein paar tausend Aufrufe hat aber nicht alle Fehler das Programm anhalten sollen - sondern lediglich als Information irgendwo stehen sollten. Damit kannst du z.B. immer wenn 20 Exceptions auftraten, die wegschreiben und so weiter (damit hat die Hauptprocedure mehr Rechenzeit, als wenn du jede Exception einzeln wegschreibst statt auf einmal 20)

Gruß

[MStoll]

@Olli:
Schon mal ne einleuchtende Erklärung ;).
Kannst du mir dann den Unterschied erklären, d.h. warum es bei einem try..except-Block um die aufzurufende Prozedur herum funktioniert?

BTW: Ich nutze in der DLL und im Programm den NexusDB MemoryManager.

[Olli]

Zitat:

Zitat von MStoll

@Olli:
Schon mal ne einleuchtende Erklärung ;).
Kannst du mir dann den Unterschied erklären, d.h. warum es bei einem try..except-Block um die aufzurufende Prozedur herum funktioniert?

Nicht wirklich, weil eigentlich Exception-Handler pro Thread registriert werden ...
Daher sollte eine Exception so oder so abgefangen werden, wie sie weitergeleitet/abgefangen wird, entscheidet aber der Code und das ist sehr spezifisch und ohne den Code nicht wirklich zu sagen. Daher hatte ich mich auch auf Allgemeinplätze verlegt ...