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:
EurekaLog has two states which controls if EurekaLog should be active or not: a global state and a local (per-thread) state.
EurekaLog will be active in a particular thread only if both conditions are true:
If global state is enabled, but local per-thread state is disabled - then EurekaLog will be disabled (in this thread). If local state is enabled, but global state is disabled - then EurekaLog will be disabled.
By default, EurekaLog is active globally and it is enabled for main thread only. Therefore, no additional actions are required for single-threaded applications (apart from adding EurekaLog to your application): because a single-threaded application contains only main thread, and EurekaLog is always enabled for main thread by default.
Multi-threaded applications is more complex, as multi-threaded application contains additional threads. EurekaLog should be enabled in a particular thread in order to work. Main thread is always enabled - regardless of EurekaLog's options. However, any background thread is disabled by default. You have to enable EurekaLog for your background threads. This can be done in two ways:
See also:
|