<p>Am 27.06.2012 15:59 schrieb "kyan" <<a href="mailto:alfasud.ti@gmail.com">alfasud.ti@gmail.com</a>>:<br>
><br>
> I am sure that this has been asked before but I couldn't find an answer.<br>
><br>
> I am in the process of porting a large application consisting of an<br>
> exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE<br>
> with hopes of being able to finally port it to Linux. I have managed<br>
> to overcome all obstacles but this seems like a brick wall: An<br>
> exception raised from a dll that is not handled by the dll's code will<br>
> crash the exe, bypassing any try/finally/except handlers around the<br>
> call into the dll that raised it. This is of course a complete<br>
> showstopper because the API and code of the dlls is way too massive to<br>
> re-engineer so that it does not let exceptions bubble up to the exe.<br>
><br>
> In Delphi without packages the aforementioned situation can be handled<br>
> reasonably well because despite the fact that operators "is" and "as"<br>
> won't work on the dll's Exception object (its class pointer points<br>
> inside the dll's Exception class and not the exe's Exception class) at<br>
> least the exception handlers work so one can display an error message<br>
> and keep the main application loop running. It is solved perfectly if<br>
> one builds all executables with runtime packages so that there is only<br>
> one Exception class for the exe and all dlls. But in FPC there are no<br>
> "runtime packages" in the Delphi sense, therefore there doesn't seem<br>
> to be a solution to this.</p>
<p>The problem is the following: the exception mechanism in FPC is implemented in a FPC-only way and only interfaces with the OS at certain points. To be more precise in Windows we use the API SetUnhandledExceptionFilter which registers a callback function with the OS which is called once an exception anywhere in the program (this includes DLLs) happens that is not handled by a SEH handler. FPC does not support such SEH handlers, thus if an exception is raised in a DLL (and here more especially an external, non-FPC exception) the unhandled exception handler callback is called which tries to find a fitting FPC except handler. I don't know the exact implementation of the handler, but it might be that it either ignores exceptions which happened in loaded DLLs (which leads to Windows terminating the process) or terminates the process itself.<br>

On Win64 it was started to support Windows' SEH (you need to build complete trunk with "-dTEST_WIN64_SEH" to enable it), but this won't help you for Win32 and WinCE. Adding support for WinCE on ARM might be rather easy though (maybe not for you, but for someone experienced with the topic) as it has a similar scheme as Win64. Win32 uses a different approach though, so this will no be that easy...</p>

<p>Unix based systems might be a different topic altogether. I've no experience regarding cross module excetions on *nix, so I can't comment whether it works or not...</p>
<p>> Can someone suggest a solution, even if I have to manually apply a<br>
> patch to FPC and build it myself? Because if there isn't one I will<br>
> have to scrap the whole project.</p>
<p>You could try to fiddle around with the unhandled exception handler callback in the system unit, but I can't help you there...<br>
Nevertheless you need to search for SetUnhandledExceptionFilter in %fpcdir%\rtl\win32 and then look for the function that is given there as an argument.</p>
<p>Summa summarum: don't let exceptions travel past the DLL boundary. One might be able to fix it on Windows, but *nix maybe not so much...</p>
<p>Regards,<br>
Sven</p>