--- title: "Some debugging tips" url: "https://osherove.com/blog/2003/8/24/some-debugging-tips.md" canonical: "https://osherove.com/blog/2003/8/24/some-debugging-tips.html" published: "2003-08-24T07:41:00" updated: "2003-08-24T07:41:00" tags: [".Net Original"] author: "Roy Osherove" description: "I was pretty sick last night and only got 1 or 2 hours of sleep. I had to stay in a little to sleep it off but now I feel better. I thought I'd put out a quick post before I get off to work. A lot of people don't know…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Some debugging tips By Roy Osherove August 24, 2003 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published August 24, 2003; technical details may be outdated. I was pretty sick last night and only got 1 or 2 hours of sleep. I had to stay in a little to sleep it off but now I feel better. I thought I'd put out a quick post before I get off to work. A lot of people don't know that in visual studio .Net , when debugging, the **Watch** window is a very powerful beast. Most people treat the data in it as read-only. It's not. You can walk up to any variable of value in the Watch window ,click on it, and write down the new value that you want for that variable. Just like that. - Not only is the **Watch** window not read-only and allows you to change while debugging, it can also **evaluate expressions** while debugging. For example, say you have a method in a class that accepts a value of type Class1 and returns as a string some information about that class. Say you are in the middle of debugging(running is paused). Pull up the Quick-watch window(Ctrl-Alt-Q) and type in the name of that function just as you would in C# (if you're debugging a VB.Net application you need to write the expression in VB.Net). So by writing **MyFunction(this)** in the quick watch window, that function actually gets evaluated and you can get a lot more information about what's going on in your debugging environment. - The same holds true for **advanced breakpoints**. You might not know it, but pressing Ctrl-B on a code line brings up the “breakpoint properties“ dialog. One of the properties in there allows you to enter the breakpoint only if some condition is true. That means you can write in there any expression that evaluates to true/false. Can you guess what I'm getting at? Yes. You can call functions inside your code that return bool values that will decide for you whether the breakpoint will hit. Not only that, these functions can also do some work in the process. They can log things, they can change things. This technique may get a little dangerous, but as long as you understand that you can seriously impact the execution path of you application if you're not careful, you can go ahead and do some real advanced debugging. - Did I also mention that you can set multiple breakpoints on the same line? You can, if you have multiple expressions on a code line. If you have a complex **if** statement, something like : - _if(MyFirstFunction() && MySecondFunction() || MyThirdFunction()) {}_ - You can actually set three different breakpoints here. To set a breakpoint only when the code executes _MySecondFunction()_ , put your cursor inside the name of the function call and hit F9. You'll see that a breakpoint is set in the middle of the code line. If you have multiple breakpoints on a single line, clicking the left side bar to clear the break point clear all of them. ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Aug 25, 2003 ### [The ultimate connection string reference](https://osherove.com/blog/2003/8/25/the-ultimate-connection-string-reference.html) - Aug 25, 2003 ### [Combobox binding trouble - with a solution](https://osherove.com/blog/2003/8/25/combobox-binding-trouble-with-a-solution.html) - Aug 21, 2003 ### [Make your app support plugins - Part II](https://osherove.com/blog/2003/8/21/make-your-app-support-plugins-part-ii.html) - Aug 20, 2003 ### [User Group notes: WMI, CLR hosting and AppDomains](https://osherove.com/blog/2003/8/20/user-group-notes-wmi-clr-hosting-and-appdomains.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/