Filters - EurekaLog Documentation

Exception filter is a filter which can alter EurekaLog's behavior based on some properties of exception. It is a easy way to customize EurekaLog on per-exception basis without writing code. Exception filters can be configured here.

Usually exceptions are identified by exception's class name (such as 'Exception', 'EAccessViolation', 'EStreamReadError', etc.). You can also identify exception by source location or values of properties. And you can identify exception by its type (handled or unhandled). Once exception is identified - you can change handler for it (none, RTL or EurekaLog), dialog class (to any of existing dialog classes), override error message, set action (restart or terminate) or mark exception as "expected". Remember, that you can also use environment variables.

Exception filters are applied before processing exception. Filters are applied in order from top to bottom. First matched filter is applied.

Example of 3 exceptions filters added to options

Exception Identification Page

Altering Behavior Page

Most typical usage for exceptions filters include:

•

Completely ignore particular exception type. This is useful for such exceptions as EAbort. You may use similar exception types in your code, so now you can use exception filters feature to completely hide such exceptions. Set handler to "none". No error dialog will be shown. No bug report will be created.

•

Excluding certain exceptions from EurekaLog's processing. For example, when disk free space is low and you try to create or write a file - an exception about insufficient disk space will be raised. You usually want this exception to be shown as error to the end user (so he/she can free some disk space and retry the operation), rather than generating bug report (and optionally sending it to you). That's because this exception is not a bug in your code, there is nothing to fix. So you may create filter for such exceptions (they are called "expected" exceptions). Set handler to RTL, and this exception will be handled as usual (by showing error message), but no EurekaLog work will be done for it (no EurekaLog error dialog, no bug reports, etc.).

•

Some exceptions (such as access violation) are low-level. Their message contains some technical information, but it's completely useless for most users (which are not programmers). Seeing such "cryptic" error messages may be confusing ("gosh, what should I do with it? Is it even a error? Or it asks me something that I don't understand?"), so it may be useful to hide them. It's better to show more user-friendly message like "Sorry, there was a error in application. Please, let us know about this problem and restart application." Such message is far more descriptive. It explains what happenned (an error) and what to do (report to developers and restart application). You may create exception filters for such exceptions, set handler to "EurekaLog" and override a error message. You may additionally enable termination/restart features for these exceptions. Note: message override affects only error message in visual dialogs. Bug reports always contain information about original exception (with original error message).

There may be other use for exception filters (just use your imagination). But the above are the most popular ones.

Important note: your exception classes must be real classes. You can not use aliases. For example:

type
EMyException1 = class(Exception);
EMyException2 = Exception;

You can specify 'EMyException1' as exception class name. However, 'EMyException2' will not work. Because there is no such class. You should use 'Exception' instead.

Important note: ensure that features specified in exception filters will be available at run-time. For example, if your application uses MS Classic-styled exception dialog by default and you want to switch to EurekaLog-styled dialog for some exceptions by using exception filters - then be sure to include code for EurekaLog dialog into your application.

Note: exceptions filter can also be created from code. Also, exception filters can be replaced with custom attributes.

Root > Customizing EurekaLog > EurekaLog options > Dynamic options > Filters Filters