You covered a lot of material today. Debugging in ASP.NET is complex, but the available tools will help you find and squash any ugly bugs quickly and easily.
One method of debugging involves using the Response.Write method to output debugging information when you execute your pages. This method can help you follow the execution of the program and locate errors. Unfortunately, you have to add and remove these statements manually so they don't display private information to end users.
You can use try and catch statements to catch errors and handle them gracefully, allowing execution to continue without problems. You can also use the throw keyword to bring up your own errors.
The trace tool provides a much better method for debugging than using Response.Write. This tool provides detailed statistical information on your page, including execution times, objects used in your pages, form and HTTP header information, and server variables. You enable the trace tool by adding Trace="true" to your page directive.
You can use Trace.Write and Trace.Warn to display custom debugging information in the trace log. These statements are similar to Response.Write, except that they don't produce any client output, so you don't need to remove them when you're finished debugging your pages. The output from these methods only affects the trace log, and even then only when tracing is enabled. Otherwise, they don't affect your application at all.
You can also enable tracing for your entire application at once by placing <trace enabled="true"/> in the web.config file. You can then view overall statistics and trace output for each page by requesting the trace.axd file on your server.
Finally, you examined the Common Language Runtime Debugger, a useful tool for watching execution while it's happening. Using this tool requires attaching it to the ASP.NET application in question, which can cause some serious side effects. To use the CLR debugger, you must first add <compilation debug="true"/> to your web.config file.
Once the debugger is attached, you can set breakpoints and step through your code line by line, watching over any variables and their values.
Tomorrow you're going to take a look at ASP.NET security. This has always been a very serious issue for developers. ASP.NET provides a number of different ways to secure your applications, and you'll examine them all tomorrow.