| Later in this chapter you'll learn how programs generate exceptions. For now it's sufficient to know that exceptions are objects that report error conditions. More specifically , exceptions are classes derived from System.Exception. Whenever you call a function, that function may generate an exception informing you that something has gone wrong. A function may generate several types of exceptions. For example, a function called MakeDeposit may generate an AmountMustNotBeZero exception and an InvalidAccountNumber exception. There is no way to know if a function is going to generate an exception, or what kind of exceptions it will generate, except by reading the documentation. You can decide to catch only certain kinds of exceptions and let some other piece of code catch the rest, or you can decide to catch all possible exceptions. To catch all possible exceptions: -
Functions don't say if they're going to generate exceptions or not, so read the documentation to see if the class throws exceptions and to learn what kind of exceptions you might get. -
Before the line that might throw an exception, type try followed by an open curly bracket { . -
After the code you suspect may trigger an error, add a close curly bracket } . -
In the next line type catch followed a space and an open curly bracket { . -
Type code to handle the exception (see Tips on next page). -
Type a close curly bracket } ( Figure 11.8 ). Figure 11.8 As this code shows, you could decide to just have one general error handler for your code. void OpenDatabase() { string cstr = "Provider=Microsoft.Jet.OLEDB.4.0;" + @"Data Source=c:\csvqs.mdb;"; try { IDbConnection conn = new OleDbConnection(cstr); conn.Open(); } catch { Response.Write("Error!<br>"); } }  Tips -
Programmers normally refer to exception-handling code as try/catch blocks. -
If function A calls function B and function B calls function C, and C generates an exception, function B can catch the exception first with a try/catch block. If function B doesn't have a try/catch block around the call to function C, then the exception gets propagated to function A ( Figure 11.9 ). If Function A doesn't catch the exception, it's considered an unhandled exception. When an unhandled exception occurs in a Web application, by default you will see a message similar to the one in Figure 11.10 . Figure 11.9. Notice that the code in the middle box doesn't have a try/catch block, so the exception flows to the first box. This would be the case also if the middle box had a try/catch block for specific exceptions only, and the exceptions being caught were different from the one being thrown.  Figure 11.10. Error pages in ASP.NET are a vast improvement over the ones in old ASP.  -
Client machines by default will see the message in Figure 11.11 . If you execute a standalone .NET application (an EXE that you double-click on, for example), an unhandled exception causes the runtime to display the message in Figure 11.12 and then halts the program. Figure 11.11. This error page doesn't reveal as much information as the one you get from a local machine. That's because we don't want potential hackers to see lines of code in our program. However, this page still isn't what you want to show your clients when something goes wrong. Later you'll learn how to customize the page.  Figure 11.12. This dialog is equivalent to the old message box with the stop icon that usually says, "An exception has occurred in your application, press ok to stop the program and cancel to debug," for non-.NET applications.  -
You can add a function to your program to serve as a last-resort exception handler. If no code catches the exception, the runtime will invoke this function (see the topic "Catching Unhandled Exceptions" later in this chapter.) -
In your catch block you can find out information about the exception; you can write some clean-up code, like closing a file or disconnecting from a database, and then re-trigger the exception for the next level; or you can do nothing.
|
