We've recently introduced the concept of exception coding
in one of our large applications. The goal is to better categories the types of exceptions so we can empirically identify and quantify problems.
When an exception occurs, our application logs (eventually making its way to our +Splunk
server). The exception has three key pieces of information:
1. The type of exception (e.g. NullReferenceException, ArgumentException, SystemException)
2. The stack trace of the exception
3. The exception's message
The majority of exceptions we encounter are programming mistakes that affect any user who steps on the faulty code. However, because each user is different and the data they're working with is different, the log output differs. But for a given code problem, it differs only in the third piece of information: the exception's message.
Therefore the other two pieces of information do not
vary for a particular code problem: the exception type and stack trace.
So our Exception Coding
computes a hash of the exception type and stack trace and produces a simple hexadecimal code (e.g. "C76F97E1"). These codes don't need to be memorizable, but they are recognizable. And they're distinct enough visually to be easily zeroed in on in a big log message, and they're unique enough for simple string-based content searching.
Our exception codes are simple:
1. We use xxHash because it's fast, low collisions, and is available in a wide number of languages we might use throughout the enterprise
2. We exclude filename and line numbers which aren't always available (trading accuracy for consistency)
3. We reference them across the enterprise: customer support, Splunk, issue tracking, user's unhandled exception dialog, etc.
We've only had them in production a short while, but already it's helping to highlight which problems are the most frequent. And when a problem is reported by a user, since the dialog includes any Exception Code, support personnel are able to quickly recognize known problems without contacting the next tier of support.