Ganz einfach:
Man reicht einfach keine Exceptions über die
DLL-Grenzen hinaus. Es gibt Rückgabewerte und die Rückgabewerte können geprüft werden. Zusätzlich kann es noch etwas wie
GetLastError geben.
Die
Exception
selber wirft dann die Anwendung, die die
DLL benutzt (z.B. so wie
RaiseLastOSError)
Der "normale" läuft ja über Rückgabecodes. Jedoch wurde bei der Schnittstelle das Exceptionhandling vollkommen außer acht gelassen.
Das jetzt nachzubauen (Tritt ja erst auf nachdem wir XE6 verwenden statt bisher D6, Alles auf einen Schlag umstellen geht auch nicht) würde Wochen dauern. Hier muss ein Lösung her die das auf über Hooking oder ähnliches direkt löst.
Wenn jetzt die
Exception im D6-Teil erzeugt wird erkennt ja die XE6-Verison das es sich um eine Delphi-
Exception handelt. (System._HandleAnyException). Es kracht dann beim Zugriff auf den RaiseListPtr (System.ExceptObject).
Meine Idee wäre jetzt auf dieser Ebene (Vermutlich würde Hooking von TApplication.HandleException reichen) und eine Erkennung einzubauen ob das
Exception-Objekt wirklich ein D6.TObject ist. Falls nein dann die Plugins fragen ob dieses Objekt von ihnen kommt und dann über die
DLL-Schnittstelle den
Exception-Text abfragen.