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:

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:

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:

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:

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: