You develop your applications and verify that they work as intended to the best of your efforts. You have tests, both automated and manual, you have bug-hunting sessions to flush out all the edge cases and you all run the applications internally to make them as robust as possible. When you have done your due diligence you release them to your customers. At this point you traditionally lose touch with these applications and you don’t know how they actually work for your end users. They may encounter strange bugs or have applications crash on them. Wouldn’t it be nice if you were able to obtain data from these crashes and strange errors that just “shouldn’t happen”? By integrating exception tracking in your application you can.
Regardless of the amount of energy put you put into your development and quality assurance your applications is probably going to be deployed to an end user which will make it crash or otherwise generate errors. As much as you have already tested your application it is almost inevitable that some unexpected situation occurs in the real world, with the shear range of different network setups, machine configurations and unknown software installed. Relying on your user’s ability and desire to deliver good, detailed and thorough reports on these crashes and strange behaviors is really not an option so you need a way to automatically collect information on these issues. To improve the overall quality of your applications you can use the Analytics library to track these crashes and unexpected situation, enabling you to gain insights into what your customers are experiencing with your application. All this data from all your customers are aggregated and you will be able to quickly determine the scale and the context of issues occurring with your application. You will be able to proactively take the knowledge obtained from this data and take steps to remedy the issues, improving the robustness, stability and general user experience of your application as well as increasing the overall quality of your product.
The screenshots above shows a real world sample of some of the issues that are encountered by end users of an application and how the exception details are delivered with full context to the users of Analytics. These exceptions and this level of detail would have never reached the product owners without the integration of exception tracking.
The Analytics monitor library makes it simple to track your exceptions.
monitor.TrackException(exception, "My context message");
With this simple call you hand the exception instance to the monitor which will take care of all the stuff that is required to make this available to you as an application owner. The Analytics will process all the data and categorize similar exceptions to make it easier to see exactly what exceptions are happening frequently.
To be effective when tracking exceptions it is recommended to adhere to a few principles when deciding when and where to track exceptions using the Analytics service. By following these principles you will gather important information and avoid drowning in unnecessary information overload:
- Track unhandled and crashing exceptions. If at all possible, track the exception that is crashing your application or displaying large error messages to your customers. Most programming environments have a way of catching or being notified of unhandled exceptions. Track these to gain insights into what conditions are crashing your applications and what the end users are experiencing.
- Track unexpected exceptions. Some exceptions are expected, they are just part of the way the application works. For instance, connecting to the internet from your application may fail for whatever reason and in most programming environments this will cause an exception to be raised. This is not an unexpected situation and your application probably already handles this gracefully. However, some exceptions are truly unexpected; ones you just didn’t assume would ever happen. Track these exceptions to understand where your assumptions were wrong and learn more about how your customers are indeed using your application.
- Don’t track all exceptions in your application. Don’t mistake the tracking of exception with your existing logging framework. You probably already have calls to write errors and exceptions to a local logging framework and that is just fine for local debugging and tracing purposes. Tracking exceptions with Analytics should be reserved for those exceptions that you did not expect and perhaps cannot recover from.
- Provide good context. When tracking an exception you are able to provide a custom message along with the exception instance. Providing a good message that outlines some of the context of the exception such as parameters to methods, return values or other settings will assist you in determining why things failed.
These principles should help you collect high quality data from your applications that can be used for immediate improvements to your applications.
There are several ways of improving your product based on the information collected from tracking exceptions. Here is a short list that highlights some of the uses:
- Discover errors as early as possible. Since exceptions are reported to the server they will show up almost immediately. This will save you the time of waiting for end users to become sufficiently annoyed at problems to actually contact you and allow you to be very proactive in handling issues from the field
Prioritize errors based on facts. By looking at the exceptions reported you can immediately see if an exception is a one-off exception or an exception that is happening frequently and to a lot of users. This can help you prioritize amongst the exceptions and solve the ones that are disrupting your users or your business the most. A shown below, the exception report comes with details that help evaluate the severity and context of a given exception based on actual application usage facts.
Help troubleshoot errors. Using the context messages provided with the exceptions and e.g. the environment information available for the individual exception can assist in determining the root cause of an exception. Having this information available is beneficial instead of relying on less accurate data from the end user
- Ensure that exceptions do no reappear. If an exception is closed in Analytics it will automatically be reopened if it occurs in newer versions of the software. By automatically reopening the exception there is no need to rely on humans remembering to verify old exceptions.
Using exception numbers as quality measures. The number of exception occurring relative to the number of actual usages of the application can give an indication of the current quality of the application and the amount of issues an average user encounters using the application. Observing these numbers over time can help understand how e.g. new versions impact the overall quality of the application. For instance, in the screenshot below, Analytics allowed the product owner to further investigate the sudden spike in number of exceptions, correlating it to new product releases, changes in number of application usages or previously undiscovered issues in the software.
Analytics can also assist in the more advanced troubleshooting scenarios where there is contact to a specific end user in order to determine issues with the application. By utilizing the CookieID, which is an anonymous identifier available from the integrated monitor library, the end user can deliver this identifier to the support technician at your company who can narrow in on data for just this end user and thereby get additional insights into the end users specific data and what might have lead up to the issue in question.
Our recommendation is that with very low effort can begin tracking your unhandled exceptions as they occur for your end users. By obtaining this data you can immediately improve the qualilty and robustness of your applications and begin a change towards being more proactive and responsive to issues experienced by your customers.