Automatic / options - EurekaLog Documentation

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.

Automatic way to enable EurekaLog for background threads is a simple "Default EurekaLog state in new threads" option. This option is set to "Disabled (recommended)" value by default. You can change this option to "Enabled" or "Enabled for RTL threads, disabled for Windows threads" states: EurekaLog will be enabled automatically when creating corresponding threads.

Important note: it is highly not recommended to use automatic enabling. Enable EurekaLog manually for each of your threads.

However, the problem with automatic enabling is that EurekaLog will be enabled for ALL threads in your application. Consider a typical multi-threaded application:

Threads in a typical multi-threaded application

This simple application has only two threads created by you (your code): a main thread (6688) and one background thread (7952). Your code created background thread to perform lengthy calculations and to avoid GUI freezing. All other threads were created by some 3rd party code:

•	There are some threads servicing system thread pool;

•	There are service threads for system background tasks (such as doing async work for WinSock);

•	There are threads created by frameworks that you are using (such as Indy) - mostly to perform tasks asynchronously;

•	There are even threads created by Delphi/C++ Builder IDE to perform debugger tasks!

Obviously, almost all of these threads were launched with some exception handling code in mind. Creator (3rd party code) expects these threads to behave in some specific way when exception is raised in a thread. Injecting EurekaLog processing and handling into every thread would be risky and unnecessary. Normally, you should only enable EurekaLog for threads which you know. That is threads created by you, or threads which runs your code (such as threads from thread pool). You should not enable EurekaLog for arbitrary/unknown threads.

For this reason it is highly recommended to use manually controllable activation. You can use BeginThreadEx function instead of BeginThread function and use TThreadEx class instead of TThread class to create EurekaLog-enabled threads. If you can not control thread creation code (think of thread pools as example) - then you can use SetEurekaLogStateInThread function.

However, there still may be cases when you want to use "Default EurekaLog state in new threads" option:

•	Firstly, this option remains the most simple way to enable EurekaLog for threads. You don't need to review/change your code (e.g. you don't need to search&replace "BeginThread -> BeginThreadEx" and "TThread -> TThreadEx").

•	Second, there may be cases when you have no control over thread's code at all, but you still want to get bug reports for exceptions in such thread (i.e. thread's exception handling code just invokes default exception handler, which is hooked by EurekaLog).

Important Note: You can change "Default EurekaLog state in new threads" option for the above usage cases, but we recommend to use "Enabled for RTL threads, disabled for Windows threads" position when possible. Never turn "Default EurekaLog state in new threads" option into "Enabled" position until really needed.

Root > Advanced topics > Multi-threaded applications > Enabling EurekaLog for background threads > Automatic / options Automatic / options