How to use it with DLLs?

delphi package - automated exception handling
Post Reply
StackCrash
Posts: 1
Joined: Tue Jun 26, 2018 2:42 pm

How to use it with DLLs?

Post by StackCrash »

Hi. We have a large application (exe file). It loads tons of "modules" (DLLs).
We don't want the main app to crash if one of the modules crashes. Therefore, we trap all errors inside the module (DLL) so they never propagate to the main app.

We are testing now to see if we could use MadShi Except into this project (we will require 3 licenses).
How to do it with MINIMAL impact on code? The code is 'reviewed' so we would like to have no changes or as little changes as possible.
The problem is that we would need to insert a line of code to re-raise the exception for EACH Try/Except in EACH module; and also a compiler directive to turn this line of code off when we compile in 'Release' mode. And we have lots of try/except into our modules.
Is there a better way to do it?

Oh... I should mention that we are using C++ Builder 2010 (we are going to upgrade the project to Tokyo but not in the near future).
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Re: How to use it with DLLs?

Post by madshi »

Do you have some sort of template or helper function which your DLLs call in your try..except statements? If not, I'd suggest to implement something like that, to make it easier to make global changes. Instead of re-raising the exception, you can simply call "madExcept::HandleException()" within the try..except block, that should do the trick.

One thing to think about is where to put the madExcept code. The easiest solution would be to copile it into each DLL. But of course that means a lot of duplicated code. One other solution would be to compile your DLLs only with map information, but to not link the madExcept code into your DLL files. Doing that would keep your DLLs nicely small, and would reduce the code overhead. But in order for your DLLs to still be able to handle exceptions with madExcept's analyzation capability, the madExcept code must be available somewhere in your process. The easiest solution would be for the EXE to export a helper function which then calls madExcept::HandleException(). Your DLLs could then import this function by using GetProcAddress(GetModuleHandle("your.exe"), "exportedFunction"). Or alternatively you could compile just one DLL with the madExcept code linked in, and then export a helper function from that DLL. Then the other DLLs could call that exported DLL API.

The madExcept setting "link in madExcept code" defines if the code is linked in. You definitely need "link in function names and line numbers" to be active for all DLLs, otherwise madExcept won't be able to provide proper callstacks for code inside of the DLLs. The function names and line numbers don't consume a lot of space, so I think you can safely keep this enabled at all times (unless you're paranoid about reverse engineering).

Most madExcept users keep madExcept active at all times, even in release mode. The original purpose madExcept was to provide you with crash information if your program crashes on the end user's PC. So enabling madExcept in release mode is actually the intended usage. But it's your call, of course.
Post Reply