| You've probably stumbled upon errors while developing your ASP.NET pages, ranging from forgetting the runat='server' attribute to more complex errors that take days to track down. Getting errors is frustrating, and seeing a screen like Figure 20.1 can make you want to pull your hair out. Figure 20.1. A typical error in ASP.NET.
As applications get more and more complex, it becomes harder and harder to prevent potential bugs and to track and fix existing ones. Let's look at a typical example, shown in Listing 20.1. Listing 20.1 Finding Bugs 1: <%@ Page Language="VB" %> 2: <%@ Import Namespace="System.Data" %> 3: <%@ Import Namespace="System.Data.OleDB" %> 4: 5: <script runat="server"> 6: sub Page_Load(Sender as Object, e as EventArgs) 7: 'set up connection 8: dim objConn as new OleDbConnection _ 9: ("Provider=Microsoft.Jet.OLEDB.4.0;" & _ 10: "Data Source=c:\ASPNET\data\banking.mdb") 11: 12: 'open connection 13: dim objCmd as new OleDbDataAdapter _ 14: ("select * from tblUsers", myConnection) 15: 16: 'fill dataset 17: dim ds as DataSet = new DataSet() 18: objComm.Fill(ds, "tblUsers") 19: end sub 20: </script> 21: 22: <html><body> 23: <form runat="server"> 24: 25: </form> 26: </body></html> Try viewing this listing from the browser (don't forget to turn debug mode on in your web.config file). You'll see something similar to Figure 20.2. Figure 20.2. Uh oh, something's wrong with your code.
There's obviously something wrong with the code in Listing 20.1, and if you haven't spotted it already, the page in Figure 20.2 will help. Notice that Figure 20.2 highlights the exact line where the error occurred, and describes the file and line number as well. It looks like you simply have a typo on line 18: You used objComm instead of objCmd. This is an easy problem to fix, thanks to this detailed error page, and after the error is corrected, your code will work correctly. Let's explore this error page. You'll notice that it provides quite a bit of additional information about the source of the error. For example, if you scroll down in this error page, you see two links: Show Detailed Compiler Output and Show Complete Compilation Source. Expanding these links produces what's shown in Figure 20.3. Figure 20.3. More detailed error information.
Note If you don't have debug mode enabled, you might not see the links to this additional information. Refer to Day 18, "Configuring and Deploying ASP.NET Applications," for more information.
In the first section, Show Detailed Compiler Output, ASP.NET shows you what it tried to do and what prevented it from happening. The first line in Figure 20.2 shows the command that ASP.NET used to compile the ASP.NET source code. (As you can see, it uses vbc.exe, the Visual Basic.NET compiler.) After examining the compiler and business objects, everything in this line should be familiar. The compiler then produces output that helps you determine the cause of the error. This message is also shown in Figure 20.2. In the second section of Figure 20.3, under Show Complete Compilation Source, you see the complete source of the file that ASP.NET is trying to compile, including all compiler commands and CLR functions. In general, this is not a good thing to show users. First of all, most users don't want to see error messages in their applications. Second, a clever user can use this source code against you. Thus, it's imperative to use all the debugging mechanisms you have available during development to prevent errors. Fortunately, ASP.NET provides a few mechanisms to help you out. You've already seen the first one: the try and catch statements in various places, such as in yesterday's Listing 19.1. These help catch possible errors in your application. The tracing tool also helps in this manner, as well as providing additional information. Finally, the Common Language Runtime debugger is a powerful method of discovering and fixing bugs once they've occurred. | 
