Webinar: Continuous Code Improvement Series | How to Improve with AI-Assisted Workflows Register Here Today!
There are many tools avaialble to help developers debug errors. For local development, there is a great debugger built into Visual Studio. In production, you can look at log files and error monitoring solutions like Rollbar give your deeper insight into local variables and parameters.
The most popular IDE for .NET is Visual Studio and it offers great debugging tools. Visual Studio is considered one of the best development platforms on the market, and it’s easy to use once you understand how it works. Developers can put breakpoints in their code to step through each statement and watch the code execution flow. By watching and stepping through statements, you can replicate errors and find bugs.
When you click "Run" from the Visual Studio Debug menu, the code is compiled and executes. The binaries are stored in the debug folder in the solution directory, and code executes until it reaches the break point (the red dot in the image above). When the debugger reaches the break point, execution stops and you can view the variable’s value by hovering your mouse over it.
As you step through the program (using menu options or F10 and F11 keyboard shortcuts), you can use the Watch section at the bottom of Visual Studio to watch specific variables. Drag and drop variables to this section to watch as they change. This can help you find bugs in your program before you deploy it. It also helps you find bugs from user reports.
Before you start debugging, you should know the difference between logic and syntax errors. .NET comprises mainly VB.NET and C# languages. These languages are compiled and run on the target machine. If you have any syntax errors, the compiler will give you an error and won’t provide the binary files necessary to run the program. You must first fix these syntax errors before you can compile and deploy your application.
The unexpected exceptions you need to debug from production code are logic errors. Logic errors occur when you don’t foresee a condition either from user or server input and the application is unable to handle the condition. These errors are difficult to eliminate altogether, especially in a large application. Even properly tested applications can have bugs deployed to production. It’s a side of development that developers can’t escape. Before you think that bugs equate to a bad developer, realize that even the best in the field make mistakes. Google developers flagged the entire internet as malware. One simple extra "goto" statement caused serious security issues in iOS. Microsoft accused its legitimate, paying users of piracy when a bug locked them out of Windows XP. If it can happen to the best, it can happen to you.
In production environments, you don't typically have access to your debugger. You should have the best tools to find and fix errors before they frustrate users. The way to handle bug discovery and analysis is to have the right monitoring tools in place. Operating systems and hosting software log errors, but few people have time to investigate them. It could be days before users bring problems to your attention. Even worse, some bugs could have critical security vulnerabilities.
You could use local logs and core namespaces in .NET, but then you must manage the code involved, log locations, security, and storage. What’s lacking from a majority of logging solutions is the ability to search and analyze errors. You can write errors to a log file, but you’d need to manually parse data and create your own reports by hand or by using a separate log management solution.
Rollbar is a solution that helps you monitor, search, and find quick solutions to your application bugs. By using Rollbar, you get the benefits of an Event Viewer application but in production and at scale.
Adding Rollbar to your exception handling provides a better way to log and review errors, and you can set alerts when certain events occur. In the "Error Monitoring, Not Just Logs" section, you saw the Rollbar dashboard. You can also get a snapshot graph of errors.
Go back to the main project dashboard and click the error to get more details.
On the item view page, you see a number of tabs that provide more information about an error. The "Occurrences" tab provides the number of times the exception was thrown. You could use this tab to prioritize your debugging and revisions in an application. An error that occurs 100 times a day might be higher priority than an error that occurs a couple times a day.
In the top-right corner, you can assign a developer to the error and set it as resolved in the top-left corner when the error is no longer an issue.
Go back to the main project dashboard and click "View All." With the “View All” dashboard, you get a list of all errors where you can filter and review each exception type.
Now you can perform a search to find specific events logged to Rollbar. As you can see from the image, you can also filter events by their log level. You can drill down to specific events and find the ones that could be frustrating your users the most and crashing the application.
Additionally, Rollbar uses RQL and lets you write database-like queries from your logs. This view is beneficial when you need to customize your queries, group results, and perform advanced searches without the front-end limitations.
Some exceptions are difficult to analyze and a stack trace or custom exception message isn’t enough. With .NET telemetry, you see a timeline of events that happened before the exception occurred. With this information, developers can more easily replicate the issue and simulate the environment. This includes user input, logs, and other errors. You can find the Telemetry section under the stack trace in a logged event.
As a developer, you can’t avoid debugging but you can make it much more efficient. Having exception handling is nothing new for a developer, but finding better ways to report and search errors in your code is difficult. With Rollbar's many features for .NET, developers can find issues and fix them before they become critical outages.