Root > Advanced topics > Multi-threaded applications > Creating threads > Frameworks


Previous pageReturn to chapter overviewNext page   

Important: as a general rule, you should write your application in a such way that it will behave correctly without EurekaLog on board. This means that if your or 3rd party code throws an exception in a thread - it must be handled in a way that you expect. For example, by showing an error message, canceling action, retrying, etc. Once your application behaves like it is supposed to do - then you add EurekaLog for it. EurekaLog will auto-handle all unhandled exceptions automatically (by hooking few well-known places), and for everything else - you can call EurekaLog from your own handlers when needed. In other words:

Incorrect: your application does not show messages for exceptions in thread and you are adding EurekaLog in hopes to fix this behavior;
Correct: your application correctly handles thread exceptions and you are adding EurekaLog to receive reports about such exceptions.


There are many different threading frameworks for Delphi and C++ Builder. Examples of threading frameworks are OmniThreadLibrary and AsyncCalls. There are few more less known threading frameworks. Also, a threading library can be included into bigger framework. For example, Indy have threading sub-library, JCL have synchronization primitives, etc.


Threading frameworks offer additional features, simplify common tasks, provide cross-platform approach, etc.


Different frameworks provide different ways to handle exceptions. You should refer to documentation for the framework. You should complete two tasks to use EurekaLog with threading framework:

1. Enable EurekaLog for threads created by threading framework;
2. Call EurekaLog exception handler for unhandled exceptions in threads.


Though, each framework is unique - we may suggest commonly used approaches.



Enabling EurekaLog for threading frameworks

Typically you can not control thread creation inside framework. Threads are created and managed entirely by the framework. This means that you can not use code like BeginThreadEx function or TThreadEx class. Therefore, you can enable EurekaLog for framework's threads in two ways:

1. Automatic via options (not recommended);


Note: threads created by threading framework may be used as thread pool. This means that a single thread may serve many different tasks. A good code should preserve thread state - such as thread priority, FPU state, thread name, EurekaLog per-thread state, etc. Therefore, it is better to clean after your task - as indicated in this example.



Calling exception handler

Threading frameworks use custom exception processing most of the time. Again, the exact details on exception processing are specific to a particular framework. So, we can only look at some common possibilities:


a). Calling default exception handler

If your threading framework calls default exception handler to handle thread exceptions - then you don't need to do anything (since default exception handler will be hooked by EurekaLog). See also: how to handle an exception.


b). Re-raising exception

Some frameworks may automatically capture thread exception and re-raise it into caller thread. If this is the case - then you don't need to anything (since exception from thread will be captured by exception handling code of your existing thread).


c). OnTerminate-like event

One of the typical ways to handle exceptions is utilizing OnTerminate-like event handler. A framework may offer a feature to register/install a custom callback function which will be called when thread or task is completed - so called OnTerminate event. You can register your function as handler for such event and analyze thread termination state. You can see an example of this approach in the similar illustration for the TThread class.


d). Explicit try/except block

For all other cases it may be easier to just wrap your thread code into explicit try/except block and call exception handler manually. See example here.



Additional notes

EurekaLog has additional support for OmniThreadLibrary:

Thread names from OmniThreadLibrary are passed to EurekaLog;
Call stacks for exceptions in OmniThreadLibrary threads are filtered to exclude service calls (OmniThreadLibrary internal functions).


You should include EOTL unit into your application to enable the above mentioned integration. EOTL unit is located in \Source\Extras folder of EurekaLog installation.



See also:

Send feedback... Build date: 2022-03-28
Last edited: 2022-02-15
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: