Debugging a C# .NET Application in Visual Studio Code

The Visual Studio Code Debugger

When you start learning C#, or any programming language really, it can be very difficult to read your source code and understand exactly where an error is occurring. In situations like this, it is easier to find errors by executing your application in a controlled environment. A controlled environment is one where you can execute the application line by line, or section by section, stopping regularly to inspect the environment and understand the values that variables currently contain.

The debugger in Visual Studio Code lets you do exactly this.

Let's look at how to use the debugger in Visual Studio Code.

When running an application with a debugger, you can pause the execution of your program at a specific line of code to inspect the environment before that line of code is executed. You tell the .NET Runtime that you want to stop at a specific line of code by adding a breakpoint to that line of code in Visual Studio Code. To add a breakpoint to a line, simply click on the margin to the left of the line number. A red dot appears indicating that a breakpoint has been added.

You can remove a breakpoint, by clicking the breakpoint again.

Now, when you run the application with the debugger, the debugger will pause the execution of the application before this line of code. Since we are pausing execution before this line is executed, we can check the value of the args array before the exception occurs. To run your application with the debugger, click on Run > Start Debugging in Visual Studio Code or use the keyboard shortcut F5.

The application runs and halts when the debugger hits our breakpoint. We can see where the execution is halted because the next line of code to execute is highlighted in yellow.

If we hover over the args array or look in the Variables pane, we can see information about this variable. The expression string[0], indicates that this is an array of strings that has zero elements.

Intuitively, we can understand that trying to access the first element in an array with zero elements is a bad idea and will trigger an exception. Now we know what the problem is. We can also verify that this is where the exception occurs by clicking on the Continue button in the debug toolbar or using the keyboard shortcut F5. When you choose to continue, the debugger will continue executing your code until the end of execution is reached or it hits the next breakpoint.

Other buttons on the toolbar allow you to incrementally execute the code in the application in different ways. The Step Over button will not follow execution into a method, whereas the Step Into button will.

Once you continue, the debugger immediately reports that an unhandled exception has occurred.

You can now stop debugging, using the Stop button in the debug toolbar.

Now we know where the exception is occurring and what is causing the exception. So, what will we do about it?

Working with Conditional Statements

The exception is caused by our code attempting to access an element of an array that doesn't exist because the user hasn't provided the correct input.

You may make the argument that the exception is caused by a user not using our application correctly, however, users will always use your applications incorrectly. As a programmer, it is your job to understand the ways that people might abuse your application and ensure that it works anyway. It is easier to handle exceptions than to change the behaviour of every user on the planet.

Since we don't know how to handle exceptions yet, we can avoid this exceptional situation by checking if a user has provided an argument while running the application. If the user has provided an argument, then we will print a personalized greeting otherwise, we will print a generic greeting.

What we have just described is something called a conditional statement. With a conditional statement, we can change the flow of execution based on whether a certain condition is true or false. In this case, the condition we will check is the length of the args array. If the length of the args array is greater than 0, then the user has provided the application with an argument that we can use to print a personalized greeting.

It turns out that an array has a property called length. We'll talk about properties and methods later when we learn about object-oriented programming. For now, just know that a property is a piece of data that is attached to an object like the args array. We can access an object's properties using the dot operator followed by the name of the property. In this case, we can access the length of args with the expression "args.length"'.

The conditional statement we will use here is an if-else statement. With this type of statement, you check the value of a Boolean expression. If the value is true, then you execute one piece of code, else you execute another block of code.

In C#, an if statement starts with the if keyword followed by the condition to be evaluated in parentheses and a code block to be executed if the condition is true. In this case, we want to check if the length of args is greater than 0. If that condition is true, then we will print the personalized greeting. in C#, you can use the angle bracket operators to check if one value is greater than (>) or less than another (<). You can also check equality using the double equals operator (==).

This is a valid construct by itself - an if statement does not necessarily need an else statement to go with it. If we left the application like this, the code in the if statement would only execute when a user passed an argument into the application. When a user didn't pass an argument into the application, nothing would be printed to the console, but the program wouldn't crash.

To add an else statement to an if construct, we can use the else keyword immediately after the if statement's code block. The else statement doesn't need a condition because the code in this code block is executed when the condition for the if statement evaluates to false. Inside this else code block, I will add the code to print a generic greeting to the Console.

Run the application again and verify that it no longer throws an unhandled exception and that the output is as expected. You can see the output of the application in the Debug Console.

We should also check that the application still works correctly when the user passes in an argument. You could test this without the debugger in the Command Prompt window, but you can also configure the debugger to pass arguments to the application when it launches.

To do this, open the launch.json file, under the.vscode subfolder.

This file tells Visual Studio Code what to do when it runs an application. There is a lot of information here, but the most important part for us is the args section. In this section, we can specify what arguments to pass to the application when it is launched from Visual Studio Code.

I have added the name Ken, saved the file, and launched the application again to check that the application is printing a personalized greeting as expected. Note that the value in the args array has to be a string, wrapped in double-quotes.

Conclusion

In this part of the series, we learned how to find and fix bugs in our C# .NET projects. We saw how to figure out what exceptions are being thrown in our code and where the problem is using the Console messages. We also saw how to use the debugger in Visual Studio Code to inspect the environment while our application is executing to figure out what exactly is going wrong in our code. Along the way, we learned how to use conditional statements to branch the flow of execution and avoid exceptional situations.

Before moving on, I would encourage you to spend some time playing with the debugger. Step through the whole application line by line, add multiple breakpoints, and figure out the difference between Step Over and Step Into. Debugging exceptions is a normal and important part of programming in C# so you should be comfortable and competent with the tools that are used.