Root > Solving bugs in your code > Expected exceptions

Expected exceptions

Previous pageReturn to chapter overviewNext page   

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 (e.g. 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 (e.g. not due to 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".

 

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).

 

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 (e.g. 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.

 

 

See also:




Send feedback... Build date: 2018-11-26
Last edited: 2018-08-16
PRIVACY STATEMENT
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.


Permanent link to this article: https://www.eurekalog.com/help/eurekalog/expected_exceptions.php