Take Control Over Your Errors with Automated Error Handling!

I have been a programmer for more than twenty years, coding in everything from Assembly to Ruby. During this time, I have always been frustrated with error handling. In this article, I am going to explain why and what we have done to solve this painful problem

The problem with errors

Let’s start from the beginning and why bug reports from users and log files are not a perfect match

The Tale of the Perfect Bug Report

If you ever experienced getting an error in somebody else’s application, then what did you do? Maybe you took the time to write a proper bug report, found where to report and submit it. You might even have waited in a support queue to be able to report the error.

After all, this is what we expect every user to do. As for the reports that come in, do they contain enough information to understand the reason why the error happened?

Perfect bug reports are like unicorns. Sounds like awesome creatures but don’t really exist - which is fine. In the real world, we must be realistic about what users report. Let’s face it, most of them are not technical enough to realize the importance of detailed error descriptions or what’s needed to reproduce errors.

Depending on the type and size of an organization, bug reports can be received in a couple of different ways. It might be that your situation or business is such that customers call or email you directly. Maybe there is a function set aside, a customer service or a support department that receives and registers bug reports.

The problem is the need for administration. Someone has to identify duplicates, extract information from the different reports, prioritize, find the correct log files, send status updates to your users, etc.

The tail of the log

If we receive error reports that don’t help us identify the root cause of the error, we need to do something else. One suggestion is to try to interpret what the user did. Another is the approach of trial and error until we think we have reproduced the user’s error.

Enter log files!

Most of you have probably used log files and are well versed in basic logging principles. My experience is that a team is good at writing useful log lines at the beginning of the application’s lifetime, but that discipline is hard to maintain over time, even a couple of months later.

We all know a log line like:

_logger.Error("Failed to save user", exception);

.. isn't helpful since it just repeats the error message without giving a clue to why the exception was thrown.

We have all been there, even though wishing not.

What else can we say when we have no clue about what the user did when the error occurred. The bug report is of no help. The log contains detailed information, but not what’s wanted.

Classical Error Handling

My experience is that users tend to ignore the errors if they can continue working. Since they have work to do, writing a good error report is not just a priority. Neither is sending it.

If, however, users cannot get around the problem, they might report using the most accessible path possible. Perhaps they choose to give somebody a call or use email for reporting rather than using the bug reporting software. As so few users report the errors, reacting to reports is essential, because it is highly likely that several other users have already experienced the same error.

Even if there is only a single log file, errors exist in all your environments. So, it is necessary to search for exceptions in dev, test and production. Then comes the task of comparing those logged exceptions to see if they are new or repeated ones. In the end, you cross your fingers and hope that there is enough logged information to understand why the exception occurred.

The Coderr Solution

The purpose with Coderr is to give you back control and give you a complete view of what is happening. Coderr automates most of the tasks mentioned earlier. Further, Coderr detects exceptions, collects information about why they happened, analyzes the information and finally guides you through the entire error handling process.

The error handling process can be defined as a series of steps, described above. Let me explain further how Coderr assists you throughout the process.

Discover

Periodically scanning log files for errors and relying on users to report, creates a time gap between error occurrence and awareness. Not to mention the ability to find all the errors.

With Coderr, you do not have that. Just install a nuget package in the application and add these three lines of code:

var url = new Uri("https://report.coderr.io/");
Err.Configuration.Credentials(url, "yourAppKey", "yourSharedSecret");

// This line varies between the nuget libraries
Err.Configuration.CatchMvcExceptions();

That’s it! All information that Coderr generates is from those three lines of code.

By configuring the nuget library, Coderr detects all unhandled exceptions, collect context information and upload everything to the Coderr Server for analysis. The collected context information varies between the nuget libraries. For a web application it can be the POST:ed view model or the HTTP request, for a WPF application it might be a screenshot of the failing window. Thanks to the context information, there is no need to log what the user does to be able to understand why the exception happened. In most cases, the information that Coderr collects is enough to reproduce the error. More information about the context collections can be found later in this article.

You can also configure Coderr to notify you as soon as a new unique error is detected. This enables immediate attention and action if desired, as Coderr is always at work.

In Coderr, the “Discover” section provides a complete view of all your application’s errors, in a snapshot. Here, the purpose is to track the number of errors over time while giving control and the opportunity for appropriate action. In this view, you identify which error to correct next.

Identify & Prioritize

In the above screenshot, the line “Number of error reports” corresponds with the number of times that someone working with log files would have found the error as different exceptions. Or even more unlikely, the number of bug reports that users could have sent. However, Coderr has determined the 560 error reports in this example to represent only 19 unique errors. Coderr defines unique errors as “incidents”. ITIL defines “incident” as:

Quote:

An unplanned interruption to an IT Service or reduction in the quality of an IT service.

In Coderr (Community Server), one uses the search function to find which errors to prioritize.

You can limit the search by using tags, context data (for instance the request URL) or any other information that Coderr packaged together with the error.

Once you have found an incident, you can click on it to take a look at it:

Coderr include the application version out of the box for all errors which enables you to see if the same incident appears in the latest version of your application or in more versions. To correct an incident, you assign it to yourself or someone else.

Reproduce Errors

Reproducing is fundamental to error-correction, but you need to be sure you are correcting the right part of the code base. If not, there is a risk of doing a workaround and not a bug fix.

After assigning the incident to yourself in the Discover-view in Coderr, it is time to start to analyze it further. The second top menu item, “Analyze”, is for that. In Analyze, Coderr loads one of your assigned incidents. Below is shown an example of what the view might look like.

• Tags, here `console-application` in the example shown above, can be used to categorize incidents to make it easier to find them. Read our tag documentation for more information about how to use tags.
• The error message, exception type and stack trace are the same as in a log file.
• The application version is interesting when checking out a specific codebase. Especially useful in desktop applications when customers can be assumed to be running different versions.

The most relevant part in the screenshot is the context data (in the “Context collections” area). Here, Coderr has packaged together essential information with the exception, at the time of error report generation.

The screenshot above shows information in Coderr for a selected view model. The nuget packages provide different types of context information which are all helpful when reproducing errors. We believe this to be an essential part in error-correction, making it both easier and more accurate.

Below are examples of context information from two of Coderr's nuget packages.

WPF

For WPF, you can get a screenshot of the window that failed and the corresponding view model:

ADO.NET

For ADO.NET, you can get the failing SQL statement including all parameters. You can also get the full command history for the connection that the SQL statement failed on.

Customizing Coderr

Let’s look at how Coderr can be customized to fit your requirements.

Streamlining User Error Reports

I claimed earlier that since most users have their habits and personal preference, it can be hard to get them to report bugs in a similar fashion. Coderr solves this inconsistency issue by automatically showing an error dialog to the user when an error is detected.

The above error page is activated in ASP.NET MVC by using the following configuration line:

Err.Configuration.DisplayErrorPages();

The error view can be customized/replaced so that users know that it is from your team. You can also let them enter their email address which allows you to notify them when the incident has been corrected.

Coderr always checks if there are users waiting on a notification when an incident is closed. If there are, Coderr asks if you want to notify them:

We recommend clicking on “Notify users” as users have signed up for status updates and therefore expects to get a notification when the incident is solved. When choosing “Notify users”, a new view is loaded allowing you to write a message to the users.

Write a message and click send. Coderr emails all users that signed up for status updates for this error.

For an administrator, the great benefit is that all bug reports are now automatically assigned to the correct incident in Coderr. Having all the bug reports in one place makes administration so much easier as well as provides updates to users.

Reporting exceptions manually

Coderr will by default catch all unhandled exceptions, but sometimes try/catch blocks are necessary.

To be able to report exceptions manually, use the Err.Report method. The second parameter is used to include context data, like in the example below:

try
{
    addUserInOrganization(id, user);
}
catch (Exception ex)
{
    Err.Report(ex, new{id, user});
}

Once reported, the information appears in Coderr server as follows:

The reporting guide explains this in detail.

Already using log4net? Use our log4net adapter during a transition period. It will report all logged exceptions automatically to Coderr. Your log message is also included.

Getting more details out of the exceptions

When logging exceptions, most logging libraries use exception.ToString() which only includes a subset of the information that an exception contains. Coderr processes the exception and generates a context collection from all exception properties.

A classical example is Entity Framework. There is an exception called DbEntityValidationException. When being logged it output something like:

Quote:

Validation failed for one or more entities. See ‘EntityValidationErrors’ property for more details.

Not very helpful. You know what the error is, but not what caused it. There is a question at stackoverflow with 651 votes asking how to get the real error message.

Coderr helps you with that out of the box. Here is a part of the context collection that Coderr generated automatically for that exception:

One clearly sees the entered property values and which properties that failed the validation.

As a result, there is no need to read the documentation for every exception to see which information that exception.ToString() includes.

Conclusion and Your Next Steps with Error-handling

We are all aware of errors as they are part of a programmer’s life. For some of us, it is a daily task. If you have good knowledge of the code, then you get by using log files or a log file handler, the most common approach used today managing errors.

In this article, I have shown how Coderr automates much of the labor-intense error-handling tasks and getting more accurate, faster and ultimately better resolutions to the errors. The best way to find out what Coderr can do for you is to try out Coderr yourself.

This article has focused on our Open Source version. You can compare editions on our homepage, or download Community Server from github.