Exceptions in Production mean something is wrong. It may be a situation you anticipated, like reading a value into a field of your code from a database, only to discover the value is invalid. In these cases, you can catch the exception and handle it gracefully. If you didn’t anticipate the situation, then in the best case, you got lucky, and the error is not manifested to your customers. Still, these errors can recur, build up, and eventually, bite you in the butt. In the worst case, the s**t can really hit the fan, and all sorts of bad things can happen; your website could go down, medical equipment may malfunction, stocks can tank…or worse (and these things quickly become bash festivals in the media). Either way, you need to handle these situations, especially those you didn’t anticipate. The only way to make sure nothing gets through is to have a sentry that never sleeps, needs no supervision, and constantly watches your application, immediately pouncing on any exception that is thrown and letting you know about it so that you can contain the situation before your customers notice. At Ozcode, this is what we call Autonomous Exception Capture, and it’s one of the pillars of Production Debugging.
How does Ozcode catch exceptions autonomously?
Ozcode Production Debugger uses an agent that runs next to and monitors your application. This is your sentry. When your application throws an exception for the first time, the Ozcode agent adds some light-weight instrumentation to the binary code along the full execution path from the initial interaction that triggered the exception to the line of code that threw it. But you can’t debug the exception yet; you can only see it in the Ozcode dashboard.
Next time your application throws the same exception from the same place in the code is when the magic happens. This time, when your sentry is ready to record the dirty deed down to minute detail. The instrumentation added first time around records:
- the line of code that threw the exception
- the code execution flow across the complete call stack
- local variables, method parameters, and return values
- the relevant log entries leading up to the exception
- network requests
- database queries
- HTTP requests (both the incoming request that led to the exception and any outgoing requests to external services)
Once the agent has captured all these details, it can now remove the instrumentation. Not only does the instrumentation have no significant impact on your code, once the exception repeats, the instrumentation is gone altogether, so there’s nothing to worry about there. But your sentry never sleeps and continues to monitor and count the exceptions so you get an idea of how frequently they occur, which could be an indication of their severity.
As developers, we know that what you really want to do is develop awesome code. Debugging is a chore, especially when it’s a production bug that blindsides you 2 minutes before you’re ready to head home for the weekend. But let’s think about this for a second. Autonomous exception capture removes many developer nightmares connected to debugging.
You don’t have to recreate the production environment and the exact scenario that triggered the exception in order to reproduce the bug. It’s all there, recorded for you in the exception capture. All the information you need is assembled in a familiar IDE-like environment. You don’t need to piece together a bunch of disparate log files. You can trace the code execution flow from the moment your application threw the exception back to the original interaction without having to mess with microservices, serverless code, and other complicating factors. Basically, you click a link and start stepping back through the code with full visibility into your application’s state at every step of the way until you see exactly what went wrong.
A developer’s best friend is his QA engineer
If you’re a QA engineer finding bugs may be your “thing,” but reporting them? That’s when it becomes a chore. Don’t worry; your sentry has done the work making it easy for you to create the perfect bug report in a click.
You don’t have to work hard to find the bugs; the Ozcode agent notifies you directly in the dashboard when the application throws an exception. You don’t have to investigate the exact build number or environment in which the bug manifested because your developer friend doesn’t have to recreate the build or the environment. You don’t even need to describe the steps to reproduce the bug (you might not even have a clear picture of how to do that). You don’t have to scratch your head about which log files to attach or where to dig them up from. All you do is share a link with your developer who can now immerse themselves into the runtime context of the bug and start analyzing what went wrong. Best of all, you’ll never hear, “But it works on my machine.“ Developer is happy, you’re happy, Developer and QA are BFFs.
No exceptions shall pass
There’s really no better way to monitor your application for errors. An autonomous sentry (aka agent) that constantly watches for exceptions catches them and records what happened without eating up any significant resources is the best way to go. It serves the needs of developers, the needs of QA, and, most importantly, the needs of your business to fix production errors before your customers notice them.