ASP.NET 3.5 For Dummies®

20.4. Finding Logic Errors

Visual Web Developer has loads of sophisticated tools for monitoring, dissecting, and troubleshooting your code. The hard part might be knowing which tool is best for the task. In this section, you set breakpoints, step through code, examine the errors list, and use the various debugger windows.

20.4.1. Analyzing the sample page at runtime

The best way to check if a page runs is to, er, run it. Browse to the page that you created from Listing 20-1 — right-click the file in Solution Explorer and choose View in Browser. The result is depressingly underwhelming. The drop-down list appears but nothing's in it. This confirms a bug exists. The debugger helps you find it.

20.4.2. Setting a breakpoint in the code

A breakpoint pauses the execution of a program so that you can analyze the logic. When you execute a page in the debugger, Visual Web Developer compiles the code, launches the browser, and runs the code until it reaches a breakpoint.

In your buggy example, code within the handler for the Page Load event is supposed to fill the drop-down list. The Load event is a good place to look for an error. Follow these steps to set a breakpoint:

Test-driven development Large-scale, enterprise Web projects often use test-driven development where a developer writes testing code to prove that each subroutine works as expected. The accumulated tests stay with the code for repeated runs to catch bugs that slip in during further development. Geeks call errors that ...