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

What is the proper way to handle exceptions in DLL

Previous pageReturn to chapter overviewNext page   

As you should already understood by now: rule #1 when working with exceptions in DLLs is "never let exception escape DLL". That because caller may not know how to work with exception object generated by different programming language. For example, a Delphi .exe file have no idea to to read exception message from Microsoft C++ exception; it doesn't know how to properly release exception object after exception is handled. Therefore, all exceptions in DLL functions must be captured and handled by translating them to error code or other error signature as required by DLL API.


How this should be done? That highly depends on what your DLL API is. This also depends on what framework you do use. There are 3 possible cases:

1. You develop DLL by using a framework. For example: you write a control panel applet by using VCL. Or you write ISAPI module by using IntraWeb.
2. You develop DLL for already established API without using a ready framework. For example: you write a plugin for 3rd party application (like Total Commander). Or you write a global system hook (which requires DLL).
3. You develop both DLL and API specification. For example: you write your own DLL to be used by different applications.


See also: Creating bug reports for DLL exceptions.



What if I don't want to follow best practice rules?

You may want not to follow this rule ("never let exception escape DLL"). For example, you are sure that both host and all DLLs are always compiled by the same compiler version. Such usage case usually means using packages instead of DLLs. However, you may want to use DLLs for some other reasons.


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 there is no assist from RTL for tracking exception objects). This feature may work in some specific configurations. See this article for more information.


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


DLLs can:

be post-processed by EurekaLog with "DLL" profile;
be post-processed by JCL (without having JclHookExcept active);
be post-processed by madExcept (without exception tracer activation);
supply .map/.tds files (this is only useful for IDEs without any exception tracer tool installed);
supply PDB/DBG files;
Non-Embarcadero DLL can be post-processed by EurekaLog based on output from 3rd party compiler;



See also:


Send feedback... Build date: 2018-11-26
Last edited: 2018-06-14
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: