Architecting Your Software Errors For Better Error Reporting

Already you have to worry about unit testing and basic error catching, and now you’re expected to create a broader exception handling design? Most teams see individual developer errors as personal, but in reality, they impact everyone. Error blocks may belong to individual developer code, commits and releases, and for the most part are considered only on the developer level, but for development teams to improve over time, developers need to architect their errors and get serious about error reporting.

Architecting Your Errors

What does “architect your errors” mean? This phrase simply describes a technique for individual developers to more quickly identify errors. Their errors are then integrated with all other errors so they can be viewed on an application-by-application basis rather than developer-by-developer.

This method not only helps developers reduce error response time, but also improves the software delivery pipeline by pushing the entire team to make the move to continuous integration and delivery (CI/CD). They can do that because the release automation process now knows way more about code quality than it ever did before. Stopping releases that don’t pass, and letting the others deploy straight to integration labs, or even production.

It’s true that your coding and testing styles are very personal, but when team members and customers are screaming about issues, identifying their location and the responsible developer means applying the fix much faster. And, as we know, fast fixes are the key to reducing computer rage and increasing Dev Team happiness!

Developing the System

Embracing the architecting process all at once will be easier than rolling out changes one at a time. With that in mind, we have five tips for developing your architecting system.

1. Establish naming conventions and standard error messages across the team. Align error names with business logic and naming conventions from other systems. Naming should not be unique to any one developer;
2. Always include version information and details about releases or commits in your errors;
3. Identify the feature and/or unit test associated with the error;
4. Create a standard for exception handling and clearly communicate this to the entire team; and
5. Leverage error monitoring tools to quickly spot and respond to errors.

In addition to your personal architecting, the team as a whole should design a platform to collect, report and release wide all errors on the application. Rather than trivial errors, your focus should be on net new or critical errors.

Using the System

Be warned, though, architecting your exception handling processes can be just as challenging and addicting as any code block! This is especially true in terms of exception design patterns and testing your testing. Eventually this can feel a bit odd, but also rather fun when combined with a cloud-based error monitoring system like Raygun that provides a dashboard-like feel. You’ll experience your exceptions like never before!

Just like your coding style, your exceptions are personal, but the possible bugs they create are not. Taking proactive action on how your exceptions are thrown, what information is gathered from them and how they correlate with the team’s exception processes will save both time and stress.

At first, you won’t feel comfortable highlighting your exceptions. But as overall delivery and response to application bugs improves, you’ll be happy you were the champion of architecting your errors!

Want to see what Raygun can do to revolutionise the way you handle software errors and error reporting? Try a FREE 14 day trial of Raygun today!