Exception Logger: Best Practices

Question

I just started using the exception logger (EurekaLog) in my application (Delphi). Now my application sends me a lot of error messages by email every day. Here is what I have learned so far

• many repeated errors
• several letters from one PC

Although this is a very valuable contribution to improve my application, I am a little overwhelmed by the vast amount of information I receive.

What are your best methods for processing emails from your application?

Answer 1

I think you should throw away all duplicates. Leave only the number of reports. That is, if you receive, say 100 reports, but there are only 4 unique problems - leave only 4 reports, throw out the other 96 reports, but use their account to sort the reports by severity. For example, 6 reports for the fourth problem, 10 reports for the third, 20 for the second and 60 for the first. So, you have to fix the first problem with 60 reports and only then switch to the second.

I believe that EurekaLog has a BugID in its reports. The same problem has the same BugID. This will allow you to sort reports with duplicates. EurekaLog Viewer can also sort duplicates.

Answer 2

If you get a lot of information, because at the moment you are not getting any information.

So, I would say, classify your errors in groups, e.g. WARNINGS, FATAL ERRORS, etc. Then limit your letters to the most important messages (FATAL). In addition, you regularly review your magazines (day, week ...).

Answer 3

What I did with my exception log, which uses madExcept as a kernel, but my own transport mechanism, they all go into the database. Basic information is extracted from each report and placed in the fields, and the entire report is saved. The stack trace is automatically analyzed to remove unnecessary functions, leaving only a list of my broken functions.

With this case automatically, I can now “ignore” every single message that goes into it, but see a large picture in the grid that shows me simply which functions have the most problems. Then I can focus on them, look for the reasons and correct them.

My display application can also filter reports in assemblies to a specific number if I choose, so I can say that it should not include “MyWidget.BadProc” before build 75, as soon as I fixed it.

It helped me improve my application and hit the problems that people consider the most problematic without realizing.

Answer 4

This will very much depend on which errors are sent back. Obvious is the presence of errors in your application, they need corrections and corrections / updates sent to your clients.

If these are exceptions that you know may occur and you do not need to be notified, you can add "Exceptional Filters" in the Eureaka log settings to indicate how they should be handled (or ignored!).

Another option is to use the EurekaLog variables (where you can add an exception description, etc.) in the subject line of the message, and then use your email client to filter based on this.

Answer 5

I did this using madExcept. This is really useful for identifying problems that we could not reproduce.

Why am I asking why you have so many? Disabled exceptions should be few and far between. Especially if the user sees an error dialog box. I was responsible for several applications, each of which contains hundreds of installations, and I rarely received email notifications.

If they are mostly from a very small number of computers, I would work with some of these users to find out what they do differently, or how their installation might throw exceptions.

If they are on all sides, this is probably the error received during testing.

In any case, use the details to fix your code, or at least anticipate known exceptions and catch them correctly (there is no empty try..except).

Fixing hot spot issues will reduce the number of emails you receive, making random notification more manageable.