Expected exceptions - EurekaLog Documentation

Not every exception means bug in your application. Certainly, EAccessViolation or EDivByZero is always some bug, while EAbort is never a bug. And there are some exceptions which may be or may be not a bug. For example, EStreamError exception may be a bug in your file processing code. But it also may be due to malformed source file (in other words, external environment), thus it is not a bug in your code.

•	When your application raises exception due to bug in your code: you want to produce a bug report, show dialog about exception ("error message"), send bug report to you (developer);

•	When your application raises exception as normal part of processing (in other words: not due to a bug): you want to show dialog about exception ("error message"), you do not want to produce bug report, nor send it.

Exceptions that do not represent a bug in your code are called "expected exceptions". You can mark any exception as expected via various methods. Please see this article for examples of each method.

When EurekaLog processes expected exception: it disables creation of bug report, send and restart features, as well as showing technical details (call stack, etc.). Basically, processing of expected exception will only show the exception message to the user and nothing else.

For example, here is how typical exception appears in EurekaLog-enabled application:

Unexpected (typical) exception

Unexpected exception when sending is set up

However, if you mark exception as expected, it will appear as this:

Expected exception

Technically, the exception is "expected" when it has non-zero "expected exception context ID" value or non-empty "expected exception URL" (properties of TEurekaExceptionInfo class). These values work similar to RTL's .HelpContext and .HelpKeyword. When exception is assigned with meaningful context ID or URL - an additional "Help" button will be displayed:

Expected exception with a valid context ID or URL

"Help" button with launch your application's help system with the specified context ID or launch a default web-browser to open the specified URL. It is supposed that the context ID or URL are pointing to your help system which should explain user what this exception means and how he can continue.

If you do not want this behavior - simply use -1 as context ID (the default choice).

Note: if you do not use the "Help" button in EurekaLog dialog - you may want to change dialog for expected exceptions to a simple MessageBox. For example:

uses
  EEvents, // for RegisterEventExceptionNotify
  ETypes;  // for edtMessageBox

procedure ChangeExpectedExceptionsDialog
(const ACustom: Pointer;
  AExceptionInfo: TEurekaExceptionInfo;
  var AHandle: Boolean;
  var ACallNextHandler: Boolean);
begin
  if AExceptionInfo.Expected then
    AExceptionInfo.Options.ExceptionDialogType := edtMessageBox;
end;

initialization
  RegisterEventExceptionNotify(nil, ChangeExpectedExceptionsDialog);
end.

You can mark any exception as expected via various methods. Please see this article for examples of each method.

Important note: do not confuse context ID and BugID. These are two completely different things! BugID is an exception identifier, which is different for each exception (and depends even on code which has raised the exception). BugID is used to identify duplicate (the same) exception. Each and every exception has BugID assigned. Context ID is an optional ID not linked with BugID. Assigning context ID to exception will turn exception into expected exception.

Root > Solving bugs in your code > Expected exceptions Expected exceptions