Debugging C# Code in Visual Studio | Mosh

Key Takeaways

Hi, my name is Mash Hamadani and in this video I'm going to teach you how to debug your C# code in Visual Studio. As part of this, I will also talk about defensive programming and writing reliable code that does not have side effects. Ideally, this video is for beginner C# programmers. So, if you have been programming in C# for less than 6 months, this video is for you. So, I've written a small program that displays the smallest numbers in the list. So as you see on the first line, we define a list of integers with numbers from 1 to six. Then we call this method get smallests. We pass our numbers list here. And three here means return three smallest numbers in this list. And finally we iterate over this smallest list and display them on the console. So before we get a closer look at the code, let's run the application and see what's wrong here. So with control and F5. So instead of getting numbers 1 2 3 we're getting 654. So this is not the list of smallest numbers. Let's see what's happening here. So we have two methods get smallests and get smallest. Let's expand this method. So in this method first we define a list to hold the smallest numbers. Then as long as the number of elements or the number of objects in this list is less than the count that we pass to this method, we're going to run this logic. And here we make a call to get smallest method passing the list. And we expect this method to return the minimum number in that list. Next, we add this minimum number to our ultimate list of smallest numbers and remove it from the original list. So this way, the first time this y loop is executed, we should get the list of 1 to six. So I expect one to be returned and added to the smallest list and removed from the original list. Then we repeat with this list 2 to six. And we repeat this as long as we have less elements in this list than the count that this method receives as an argument. Now let's take a look at get smallest method. So here first we assume the first element in the list is the smallest number. Then we start iterating over the list starting from index one up to number of elements in this list. And for the current number if it's greater than the minimum we change the minimum. So if you're a bit experienced you know that here we have a bug. But if you didn't catch it that's perfectly fine. That's the purpose of this video. I'm going to teach you how to use debugging in Visual Studio to find bugs in your program. So how does debugging work in terms of the process? First you need to put one or more break points in your application and then run your application in the debug mode. When you run your application in the debug mode, the execution stops at your break point. And there you can inspect the values of different variables to make sure they're holding the right value. And if not, you can change your code. So I'm going to put a break point at the beginning of the main method here. You can put a break point by pressing F9 or you can remove it by pressing F9 again. And now we run the application in the debug mode. How do we do that? With F5. So remember this shortcut. F5 is run in the debug mode whereas Ctrl F5 is run without debug. So I'm going to press F5 now. So look the program started and execution stopped at the line where I put a break point. Now at this point I can look at the values of different variables or I can continue execution. There are a few different ways to continue execution. One common way is what we call step over and the shortcut for that is F10. So if I press F10 now this line is executed. So with F10, we execute one line at a time. Now I'm going to press F10 one more time and hover my mouse over smallest variable. Let's inspect this. So we have 654. So this is telling me that there is something wrong in this method. Get smallest. So let's go back. Look at this yellow arrow here. I'm going to drag this and put it back here. I press F10 to step over one more time. But this time I'm going to step into this method because I want to know what is happening here. And to step into we use F11. So remember the shortcut. F10 is a step over and F11 is step into. Now we press F10 again. So first we define a new list. That's fine. F10 again. Now at the beginning of the Y loop, F10 again and again. Now I can save my time by pressing another break point here. So next time I run the application in the debug mode, I don't have to do all these F10, F10, F11. I can just jump here straight away. So F9 for another break point. Now to save my time, I don't want to jump into this method straight away because maybe this method is doing it job properly. So first I'm going to step over it. So F10. Now let's take a look at min. So what is coming out of this method is number six. And what was the input? A list with numbers 1 to six. So, this is telling me something is definitely wrong inside this method. So, let's go back and this time I'm going to step into it. F11. Now, F10. Now, I'm going to introduce you to a very useful tool when debugging your applications, the watch window. So you can open it via debug windows watch watch one. So what is this window? We can put the variables that are of interest to us in this window and this way we can look at their values at all time. Then we don't have to hover our mouse over them one by one. It's much easier. Now look at the code here. There are a few variables that are involved in this algorithm. One is min, another one is list of zero and the last one is list of i. So I can put these variables in the watch window and look at their values at all time. So here in the watch window min, list of zero and list of i. Now note that list of I is not defined yet because I is defined in the four block and currently we are outside the four block. So we step over this line with F10. Now look at the watch window. Note that the value of min is indicated as red. Red means the value just changed. So now min is one. Let's continue execution by F10. F10 F10 F10. Now look at the value of list of I in the watch window. So the current value in the list is two and we're comparing this with min. We are saying if list of I is greater than min set min to list of I. So with this logic we're constantly looking for a larger number and this will return the maximum number in the list not the minimum. So this is where the problem resides. Now I can easily fix this by changing this condition to less than. Now let's step over it. F10. So did you notice that this line was not executed? So the value of min was not changed. And as you see in the watch window, it's still one. So it appears the problem is solved. Now I can continue stepping over different lines here, but I think we'll kind of get lost in the detail. Let's step out of this method and quickly look at the end result. How do we step out? With shift and F11. So let's repeat the shortcuts. F10 to step over a line, F11 to step into it, and shift and F11 to step out of a method. So now I press shift and F11. Look, we are back in get smallest method. Now I can step over this line and look at the value of min. So F10. I think the problem is solved. Look at the list. So our list is numbers 1 to six and min is one. So let's stop the debugger and run the application in the normal mode without debugging and see if we get the right result on the console. How do we stop debugger? With shift and F5 again to review, F5 to run the application in debug mode and shift and F5 to stop the debug mode. And now I'm going to run the application without debugging with control and F5. Awesome. We fixed the bug. But wait a second here. We're not done yet. This program has a few more bugs that you haven't seen yet. And that's what we're going to cover over the next few [Music] lectures. One thing that distinguishes a good programmer from an average one is that a good programmer often thinks of edge cases. What I mean by an edge case is uncommon scenarios. An average programmer often assumes the end user enters values into the forms the way the programmer expects. But the reality is different. So back in the example from the last lecture, look at the first line here. We have a list of six numbers. And in the second line, we want to get the three smallest numbers in this list. What if we only have two numbers in our list? So I'm going to remove these four numbers and run the application. The application blew up. We got an exception. So close the program. We got argument out of range exception. Index was out of range. So what's going on here? When you face situations like this, that's when you start debugging. So I'm going to run the application in the debug mode and find where in the code we're getting this exception what line. So remember our shortcut F5 to run the application in the debug mode. Control F5 to run the application without debug mode. So I press F5. Now okay we stopped at this break point. I want to continue execution. So in the last lecture you learned about step over, step into and step out. There is one more way to continue execution and that is continue till the next break point. So I can press F5 again and look now we are at our second break point. So so far everything seems to be fine. We didn't get an exception. So let's continue. F5 one more time. Okay. We're back on this line again. One more time. H doesn't seem to be right. You know what? I want to get rid of all these break points and just run the application and see where exactly it blows up. So, this is something that often comes up when you're building big applications. You put various break points here and there and once you fix the bugs, you forget to remove them and then these break points get in the way. So, how do we find them and how do we remove them? We go to debug. One way is to go straight here and click delete all breakpoints or disable all breakpoints. That's the quick way. There's also another way you can go to windows and break points. So here you see all the break points in your application. What file, what line, what character. You can double click go there. You can disable them or enable them or you can delete them. So, I'm going to delete both of these. Now, I want to restart the application. The shortcut is control, shift, and F5. If you ever forget these shortcuts, you can always find them. Just go to the debug menu here. So, look, we've got continue, which is F5, stop debugging, which is shift, and F5. And now I'm looking for restart, which is control, shift, and F5. So, I restart the application. Okay, this is where it blew up. So I put a break point here as my starting point. F9. Now let's look at the exception argument out of range. So what's happening? Let's close this. Look at this list. This list is empty. There are no elements here. Yet we're assuming min is the first element in the list. So this code is not really reliable and this is one of those areas that separates an average programmer from a good programmer. Now before we fix this bug, let's see why is this list empty. If you remember this line, the purpose of this was to remove the smallest number from the list and we continue repeating this until we get enough small numbers based on the value of count here. So as we're removing these numbers from the list at some point the list becomes empty in this case because our list originally had two numbers in it after two iterations the list became empty and that's why we get this exception. Now the question is how do we fix this one? We have a few different ways here. One way is to have an if block in the get smallest method that checks if the count that we pass here is greater than the number of elements in the list. The reason we're getting this exception is in this case we want three small numbers but the list is only two. So this is one way to solve this problem. Another way is to put a conditional in get smallest method. So we need to check that if the list is empty. So if the list is empty, what should we do? Should we return zero? I don't think so. Imagine if our original list, I mean this list here, had a number of negative numbers. Then at some point we get here the list is empty and returns zero. So the program end up displaying zero as one of the smallest numbers in the list which did not exist in the list in the first place. Another option is to check if the list is empty here throw an exception. So that's one of the conditions or criteria for this method to do its job. This is what we call defensive programming. So when we get input here before doing any processing we want to make sure that the input satisfies some criteria. If not we're not going to continue processing. Now there is a third way here. Can you see that? It's not quite obvious, but yet it's very important. Look at this method. Get smallest. This method has a side effect. So this original list that we sent here, we're continuously removing some numbers from it in order to calculate the smallest numbers. And side effects are not good. They make your methods unreliable and they're often hard to find bugs that are because of side effects. Now, for a second, I want to stop the debugger here. I'm going to put those four numbers back here. So, if you run the application now, everything works. Okay, we got one, two, three. But let's iterate over the original list. So, I'm going to change this to numbers. Look at the result. Our original list is changed. 1 2 3 is removed there. And this is what I meant by side effect. So in my opinion, that's a more serious problem that we need to address first. Now, that may or may not solve the bug that I introduced at the beginning of this lecture. That's fine. If it doesn't fix it, we're going to continue debugging and find the right way to fix that bug. So the first thing I want to do here is to remove the side effect. How do we do that? So in the get smallest method, instead of removing these numbers from the original list, I want to create a copy of this list to do my processing. So I call this list buffer. So we create a new list. and pass that original list here. And then instead of removing these numbers from the original list, I remove them from the buffer. And one more change here, we need to change this list to buffer. So now look, this list, the original list is only used during the creation of the buffer. Now let's run the application. Okay, beautiful. The original list is not affected. So, we removed the side effect. Now, let's get back to the original bug that I introduced at the beginning of this lecture. So, I'm going to remove these four numbers and change the for each block to look at the smallest numbers. Let's run the application. Okay, we still have a problem here. So in the next lecture I'm going to show you how to fix this [Music] problem. Okay, back here we want to fix the bug from the last lecture. So we have a list of two numbers and we want to get three smallest numbers in this list. And as you remember from the debugging session in the last lecture, this problem happened in this line here. So at some point the input list that we give to this method becomes empty and we try to find the minimum number in an empty list. Now we have two choices to fix this problem. We can put a conditional statement here and make sure the list is not empty. That's one way. The other way is to have a conditional statement in this method here. So we want to make sure the count that we get here is not greater than the number of elements in this list. Now both these solutions might sound reasonable but which one do you think is a better solution? I think a better solution at this point is to check if count is not greater than the number of elements in this list. Why? Because we're asking a question in this method, but the question itself has a problem. If the question is meaningless, we cannot get an answer. Let me use a metaphor. Imagine you ask your friend, "Do you eat with a pen and paper?" Doesn't make sense. The question should be, "Do you eat with a spoon and fork or with chopsticks?" So when the question is meaningless, we cannot provide an answer. So in this case I'm going to attack this problem by making sure this method gets smallest gets the right arguments as the question. Now so I'm checking if count is greater than the number of elements in this list then we throw an exception exception of type argument out of range exception. This is a useful technique in defensive programming. So we check the input first before doing any processing. Now one more thing I would like to add here. We can add a message here. Count cannot be greater than the number of elements in the list. Let's run the application now. The application crashed again. So have you solved the problem? Yes, we did solve a part of the problem. Now, you might ask, Mosh, how is this better than before? Because before we got an exception anyway. Let's see the difference. Read the exception. Argument out of range exception. Count cannot be greater than the number of elements in the list. So, this exception is more meaningful. It's telling me why the program crashed. So, when it comes to troubleshooting, I would have a better idea of what's happening here. I would know that the client of this method in this case this line here is sending the wrong data. Let me temporarily comment out these two lines here and run the application again. Read the error now. Index was out of range. Must be non negative and less than the size of the collection. This error message is too low level and it's coming up from a method further down in the list of method calls. So it came from this method here. The important thing to consider here is we should not get here in the first place. The program should stop execution at this point. And that's why we added this if block here. The reason I add this here is not just to display a more meaningful message. is to prevent your application from going in the wrong state. Now, this is a very simple program, but imagine if this was a big real world application with a database. If your application goes in the wrong state, there is a chance that sometimes that state gets persisted in the database and then next time you load a page, you show some data to the user that makes no sense. And in situations like that, you're going to have a hard day finding that bug. You're going to spend a day or two, maybe even a week to figure out what was happening. Okay, back to the business here. Now, we solved this problem with this count being greater than the number of elements in the list. What if count is zero? Do you think it's a valid question? Give me zero smallest numbers. No, it's a ridiculous question. What if it was minus one? It just doesn't make sense. So we need to change this slightly to something like so if count is greater than the number of elements in the list or smaller than or equal to zero that's out of range. Of course we need to change this message slightly. Count should be between one and the number of elements in the list. Let's run the application. Okay, we got this meaningful exception here because we passed minus one to this method. Now to further expand this topic of defensive programming, what if we send an empty list here? Something like this. You might say, "Okay, Mosh, we can do another check here to make sure that the list is not empty." We can certainly do that. But in this case, I can show you that the existing logic would work for an empty list. Why? Because first of all, I know we cannot send minus one or zero here. So, we need to send one. And because one is greater than the number of elements in the list, this logic will stop the program execution. So there is no need to write if list.count is zero through an exception. It's just redundant. But what if the list was null? What if I send null here? then I'm going to get another low-level exception further down the track. So, let's investigate that. Run the application. The famous null reference exception object reference not set to an instance of an object. So, this is something that I would like to prevent at the beginning of this method to make sure the question is the right question. So if list is null, we throw an argument null exception. Okay. So in this lecture we covered some of the edge cases around this algorithm and we improve the reliability of our code. And that brings us to the end of this lecture. Over the next couple of lectures I'm going to show you more debugging tools in Visual Studio. Okay, back here I changed the declaration of our list back to what it used to be. So numbers 1 to six and also added number three here. So we get three smallest numbers in this list. Note that we have one break point here. Now I'm going to run the application in the debug mode. So F5. So we are here. Now this is a very simple application with only three methods. But often a real world application consists of tens, hundreds or even thousands of classes with a few methods. So sometimes when you're debugging you might get lost. Now I'm going to introduce you to a window that shows you how you got here. This window is called stack. So you can find it in debug windows call stack. So this window shows the order of methods that were called from the moment that the application ran up to where you are now. The item on top of this list is your current location and the item on the bottom of this list is where you started. So we can double click here. That brings me here. Let me dock this window. I double click this one. So before we jumped into this method, this is where we were. Now I double click main and this is how we started. So we went to this method and then ended up here and finally in get smallest method. So if you get lost remember the call stack [Music] window and one more thing. So earlier I told you about the watch window. So you can bring it from debug windows watch watch one. Now watch window is useful but sometimes it may get a bit tedious to type the name of variables you would like to inspect. So I'm going to show you two more windows that are useful in debugging. Autos and low calls. You can find both of them under debug windows autos and low calls. So let me bring it up here. So the autos window is like a watch but with automatic list of variables. Visual Studio based on where you are in the code detects the variables that you could be interested in. So here you see it has list I which is the loops counter variable. We have the list variable which is the input into this method. List count because we have referenced it here in the code. List of I because we're using it here and min again we have referenced that here. So this saves you time. The locals window is similar to the autos window. So the difference is it does not list all kind of variations that you see in the autos window. For example, here we have only list i and min. Whereas in autos we also had list count and list of i. So the locals window shows the variables in the local scope. So depending on your preferences, you might use locals, autos, or the watch window. Well, thank you for watching. If you enjoyed this video, be sure to like it and subscribe to my channel for new videos. If you want to learn more from me, I also have a few comprehensive C# courses that you can find on my website, programwithm.com. So have a great day and I'll be back soon.