In this lesson, we're going to briefly cover the debugging features of Visual Studio. Debugging is probably the most crucial skill that you'll develop as a beginner because it's going to help you figure out where you went wrong in the code you've written. When you first encounter vexing problems in your code, you can stare at it and hope the solution dawns on you, or you can set a breakpoint and debug. Setting a breakpoint is the first step in debugging, and it determines where the execution of your code should halt in order that you, the developer, can take control. When execution is in your control, you effectively slow down the code allowing you to inspect the values of variables and Server Controls while they change.
For this lesson, create a new ASP.NET project and call it “CS-ASP_018.” Set the Default.aspx with the following Server Controls, and programmatic IDs:
In the Default.asxp.cs file write out the following code, purely for the purpose of demonstrating problem-solving via debugging:
The imaginary rules, for this imagined application, are:
A user must select a date in secondCalendar that is at least 14 days from the selected date in firstCalendar. Otherwise, an error is displayed in the resultLabel.
The resultLabel should be the sum of the TextBox and the TimeSpan.TotalDays, obtained from the dates between both Calendars, multiplied by 100.
The application intentionally has some errors when attempting to perform the calculation. Let’s now add a breakpoint to help track down the problem. You can either place your cursor on the line you want execution to halt and press the F9 key on your keyboard, or you can simply left-click on the margin beside that line of code, in this case the line that the if() statement is on:
You can also set multiple breakpoints. To demonstrate this add another breakpoint to this line of code. Do this in the Page_Load where the myTextBox.Text value is set:
Now run the application and you will notice that focus will shift from the browser back to the first breakpoint in the code execution order:
Tip: Think of the red dot, which represents the breakpoint, as being the “stop” sign in your application. Your code will execute as normal, up until the point it reaches this stop sign, at which point further execution is handed off to you.
At this point, the application is in your control. You can move to the next line of code by hitting F10 on the keyboard or by clicking on the “Step Over” icon in the toolbar. You will then see an arrow indicating the next line of code to be executed:
If you no longer want to debug this part of code you can deselect the red dot once you've stepped to another line of code, while still in debug mode, and click on the “continue” button in the toolbar. When clicking on the button, execution will then halt on the next breakpoint:
When at a breakpoint, you can then hover your mouse over different variables to inspect what values they are holding at that given moment. Here we see something that would produce an error, and that is the date held in SelectedDate:
If you hover over the SelectedDate for secondCalendar, you will also find the same problem. Note that you can inspect the values of all variables, currently in scope, by referring to the “Locals” window.
Debug > Windows > Locals
As you step into this code block (F11), notice how variables are added to the Locals and Watch Windows. The Watch Window shows you variables that you can keep track of even if they are not within the scope of the current code block. To open the Watch Window go to:
Debug > Windows > Watch
As you continue to step forward, notice how you can see variables taking on values in real-time:
The red font indicates that a value has just changed in response to something that occurred on the previous line of code (here, it is being assigned with the myTextBox.Text value):
You can also zero-in on particular variables by hovering over them. In this case, this particular variable, SelectedDate is a DateTime which means you can access constituent variables (properties) contained within it:
You can even pin certain variables down so you can see their values update with the editor itself (this stays pinned, even when done with debugging, so you can see the last value it held):
Continue to step into the code until you’re at this line:
You can even test out what would happen if variables held certain values. Go to the Locals Window and manually change days to 34:
It may seem that we changed the value for days a bit too late, as you may have noticed days was referenced on the previous line of code (in the calculation that ends up being assigned to sum). However, we can step backward to re-read the previous line, this time with the new value for days as set in the Locals Window. You can do this by right-clicking on the line you want to step to and select “Set Next Statement” (or, Ctrl+Shift+F10):
Now, when you manually step forward it will include this update to days and sum, which is then reflected in the resultLabel:
Unfortunately, not every variable is going to be so easily adjusted in real-time as we have seen here. Take, for instance, the firstCalendar property which isn’t even referenced in the current Locals Window. However, we can add it to the Watch Window by highlighting it, and then clicking/dragging it there:
After you drag firstCalendar to the Watch Window, it, along with all its properties, will be accessible there:
However, when you click on the arrow to inspect the constituent properties, you will notice that some are resistant to editing such as with SelectedDate. There is a way around this and that is by going to the Immediate Window which allows you to write code while debugging. You can display the Immediate Window by pressing Ctrl+Alt+I on your keyboard or via the menu:
Debug > Windows > Immediate
Type in the following code and hit enter to execute it:
Notice when you hover over SelectedDate you will see it storing the value you wrote in the Immediate Window:
Back in the Immediate Window, you can also query any variable to see its current values, by inserting a question mark before the variable name:
When you stop debugging, all of these temporary changes you made will be reset. However, pinned values are kept for reference purposes, and are found by clicking on the pin in the left margin:
Sometimes it’s useful to temporarily disable a breakpoint while keeping the reminder that a breakpoint was used. You can do this by right-clicking on the breakpoint and selecting “disable breakpoint” (or Ctrl+F9):
Tip: Armed with all of the information you learned from a debugging session, you should have a better understanding of how to go back and fix the problematic code. Debugging is therefore not an automatic solution to problems in your code, but more like a “magnifying glass” that clarifies the fuzzy areas.
Debugging is incredibly useful when writing code, as there will always be unexpected bugs and errors that you will write. Being able to slowly track down these errors is a very useful skill. Use these tools throughout this course to help write better code and quickly fix problems you're having. Great job so far!
Lesson 18 - Setting a Break Point and Debugging