Stack tracing: deferred vs. immediate - EurekaLog Documentation

A usual solution for exception tracer is to install a callback ("hook") which is called whenever there is a new exception raised. Exception tracer creates a call stack for the exception (full bug report is not created yet). When exception is handled - bug report may be created by using pre-created call stack.

This is common approach which will work on any platform (assuming that you can hook exceptions at all). For example:

try
raise Exception.Create('Example'); // <- call stack is created here
except
Application.HandleException(nil); // <- bug report is created here
end;

However, it also means that each exception in your application will trigger call stack collection code. This may be a performance problem if your application uses exceptions extensively (i.e. not for reporting problems). Each raise of exception will take time to build call stack for exception. For example:

try
  raise Exception.Create('Example'); // <- call stack is still created here,
                   // despite the fact that bug report is not created at all
except
  on E: Exception do
    ShowMessage(E.Message);
end;

x86-32 platform has unique architecture: a call stack may be build later - during exception handling step. This feature can give a performance gain, because exception tracer now may build call stack later - at handling state, it's not strictly necessary to build call stack when exception is raised. Thus, there will be a huge performance boost, if most of raised exceptions are handled by your code and not reach default handler (which will create a bug report and, thus, a call stack). For example:

try
  raise Exception.Create('Example');
except
  Application.HandleException(nil); // <- both call stack and bug report is created here
end;

try
  raise Exception.Create('Example');
except
  on E: Exception do
    ShowMessage(E.Message);
end;
// ...no call stack is created for this case, because bug report is not created either

EurekaLog 6 does not support multiple platforms. Thus, it always use optimized approach for x86-32 platform. EurekaLog 7 supports multiple platforms. Since other modern platforms do not have the similar feature, EurekaLog 7 does not implement the same logic globally. Instead, EurekaLog 7 implements universal cross-platform approach. However, EurekaLog 7 has "Delay call stack creation until handle stage" option. Enabling this option will bring EurekaLog 6 optimized behavior for x86-32 platform. Disabling this option will use default approach.

Thus, your Win32 applications can work with the same speed as it was with EurekaLog 6.

However, we recommend to review your code and avoid raising exceptions too often (i.e. avoid using exception as part of normal execution path; use exceptions only for errors/rare conditions) - that's because this optimization is not possible for other platforms, and your code will be slow when run on non x86-32 platform. A typical fixes for your code include:

•	Avoid raising exception when you can pre-check error-condition. For example, it's better to use TryStrToInt or StrToIntDef instead of StrToInt + try/except block;

•	Do not raise exception for non-errors. If you still need to do this - consider creating custom exception class for this purpose and exclude exception from EurekaLog (see next item);

•	You can create custom exception classes for your purposes. You can mark some exception classes as "ignored" for EurekaLog. You can do this via filters, events (specifically: OnRaise), attributes, or low-level handlers;

•	You can also add SetEurekaLogStateInThread(0, False) and SetEurekaLogStateInThread(0, True) around blocks of code which can raise exceptions intensively, but your code handles all these exceptions.

Root > Advanced topics > Stack tracing: deferred vs. immediate Stack tracing: deferred vs. immediate