How do you categorize software errors?
There are several possible axes we might think of:
- Severity: e.g. notice, warning, error, fatal.
- Module: what library or group of classes did the error come from?
- Layer: database, framework, controller, model, view.
In Exceptional Ruby, I suggested a different approach for categorizing errors. Rather than thinking of different taxonomies that errors might fall into, think about how various types of errors are dealt with. For instance:
- Inform the user that they tried to use the system in a way that is either not supported or not permitted.
- Note that the system is in a state that was never planned for, inform the user of a fatal error, and log a problem report back to the developer.
- Detect a predictable outage, and either retry automatically, or ask the user to manually retry later.
Then, once we have an idea of how different types of errors are handled and/or reported, we can work backwards from these distinctions in order to come up with a set of categories. Which we can then encode as base exception classes:
Consider a different domain: tasks in a TODO list. Again, there are a lot of ways that these could be categorized: by urgency, by sphere (work, family, personal), by importance.
The GTD system takes a novel tack: it says, “what properties are we most likely going to want to filter by?” The answers it comes up with are:
- What tasks can I do where I am right now? (Office, kitchen, out running errands)
- What tasks do I have time for right now?
Working backwards from these questions, it arrives at the idea of categorizing tasks by “context” and by time needed.
These two examples suggest a general pragmatic rule for categorizing objects: don’t worry about listing “natural” taxonomies. Instead, consider how you will most likely need to filter or sort the items.
In some cases, we might not yet know how we might want to filter or sort the objects. In that case, the rule suggests that we hold off on categorizing them at all.