Root > Advanced topics > Using EurekaLog in DLL > What is the proper way to handle exceptions in DLL > Incorrect

Exceptions crossing modules

Previous pageReturn to chapter overviewNext page   

Important: This article discusses a wrong design for DLL's API. If you want to develop a proper API - refer to this article.


procedure DoSomething;
  // Your payload


DoSomething function does not catch exceptions, and let exceptions escape to the caller module. This means that both DLL and caller module (exe) must be compiled in exactly the same version of the compiler. Otherwise one module will not know how to process exceptions from another module.


You may want to not follow rules ("never let exception escape DLL"). For example, you are sure that both host and all DLLs are always compiled by the same compiler version.



Using packages instead of DLLs

If you want to raise exception in DLL and catch it by the caller - then do not use DLLs. Use packages instead. Using packages will guarantee compatible compiler for host and DLL (package). It's also generally less problematic with all cross-modules communications.



Using DLLs

If you do not want to use packages, and prefer to use DLLs - you will need some adjustments. Since you are going to share objects (e.g. exceptions) between modules - we would strongly recommend to use shared memory manager. You can use either EurekaLog or Delphi. Your application may work without sharing memory manager, but there is no guarantee.


Such usage case means using a single instance of exception tracer in application. Host .exe must have exception tracer with enabled support for all necessary debug information formats. DLLs must have debug information source, but no exception tracer.

1. If you compile both caller (exe) and callee (DLL) - we recommend to enable EurekaLog for main exe, and use "Lightweight DLL" profile for DLLs. That way you don't have to change other options.
2. If you compile any module without EurekaLog at all - in this case you can instruct EurekaLog to handle exceptions from other modules. You can enable this behavior by disabling "Capture stack only for exceptions from current module" option. You should probably disable chained exceptions support for DLLs that let exceptions escape DLL and be handled by the caller. This feature requires ability to track life time of exceptions objects. This is not possible for general case (e.g. host and DLL are compiled by different compilers, and/or there is no assist from RTL for tracking exception objects). This feature may work in some specific configurations. See this article for more information.


DLLs can:

be post-processed by EurekaLog with "Lightweight DLL" profile; You do not need to change additional options;
be post-processed without EurekaLog; "Capture stack only for exceptions from current module" option must be turned off; Chained exceptions must be turned off;
obe post-processed by JCL (without having JclHookExcept active);
obe post-processed by madExcept (without exception tracer activation);
osupply .map/.tds files (this is only useful for IDEs without any exception tracer tool installed);
osupply PDB/DBG files;
oNon-Embarcadero DLL can be post-processed by EurekaLog based on output from 3rd party compiler;



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2019-06-17
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: