How to make sense of your stack trace and solve errors faster
Developer experience, as in User Experience where the user is a developer, is often neglected. Many of the workflows and experiences around crafting code, debugging, testing, monitoring and the whole deployment process are really rough around the edges to say the least. This mainly comes from the need to get full control of what’s going on, at the expense of making the experience smoother and enjoyable. But it doesn’t have to be like this. In fact, it shouldn’t be like this.
That’s why we decided to build Stackifier, a free online tool where you can paste your stack trace, and make sense of it. Creating a new representation with a readable design that would highlight the information you need to draw out – without compromising on seeing the full picture. Eventually compacting a never-ending stack trace which can reach hundreds of lines. This is actually a very small part of OverOps, so we thought it would be interesting to focus on it.
Minimal information loss, maximal value
Your first task when seeing a raw stack trace is to trace where it touches your code for the first time. Where was the exception thrown from in this case. All 3rd party libraries along the way aren’t really interesting, so we grouped them by their top packages and differentiated them by color.
Although, sometime you wouldn’t want to completely lose track of what’s going on in these 3rd party libraries, so we kept that information available. Each grouping can be expanded to view the frames inside the stack trace:
As to the actual frame where the exception is thrown from, we marked it with a flame. In addition, you’ll notice that there’s much less text. Stackifier only shows the SimpleName of the class and method that represents that frame in the stack trace. And the line number is highlighted on the right of each line. Much more fun, useful, and fast than making sense of mountains of text.
Logs remained exactly the same for over 20 years
Think of all the time that’s wasted on understanding or doing things that only exist because they made sense once, and were the right solution then, but haven’t evolved since. You’re used to seeing stack traces in your logs, so it’s easy to “forget” they’re produced by the application you’re running and simply printed out to be stored on file.
And what else you’re looking for when you grep on to that sequence of frames you need to be looking at? Whatever information you’ve decided to print out in log messages that would help you understand the state of those frames. That information is also drawn out from your application. So what if we could skip the log altogether, not write to file at all, and have a smart stack trace data structure that already contains the state of each frame? We could stop using logs, and that’s exactly why we originally created OverOps. OverOps is platform that tracks all errors and slowdowns (including uncaught exceptions and log errors) at runtime. It lets you see the variable values that cause errors, all across the stack, and overlays them on your code.
Developer experience is a top priority and the future of developer tools is looking both smart and beautiful. And there’s no reason to compromise on any of these parameters. In fact, when these compromises do get made, precious time can be lost on tedious tasks instead of focusing on innovating and building new features.