Build Your Own ASP.NET 2.0 Web Site Using C# & VB, Second Edition

⋮

<customErrors mode="modeValue"

defaultRedirect="errorPage.aspx" />

⋮

</system.web>

</configuration>

The defaultRedirect attribute of the customErrors element is used to specify

the page that’s used to report errors. We can then choose whether this error page

is shown to everybody, to nobody, or only to users who access the site from an-

other network using the mode attribute. The possible values for the mode attribute

are:

On

When mode is On, ASP.NET uses user-defined custom error pages,

instead of its default error page, for both local and remote users.

Off

When mode has a value of Off, ASP.NET uses its default error

page for both local and remote users. The customErrors element

has no effect when mode is set to Off.

RemoteOnly

When mode has the RemoteOnly value, the ASP.NET error page

is shown only to local users, and the custom error page is shown

to remote users. RemoteOnly is the default value, and is generally

the safest option during development. If the defaultRedirect

attribute is present, remote visitors will see the page mentioned;

otherwise, they’ll see a generic error that doesn’t contain debug-

ging information.

Handling Exceptions Locally

As you can see, unless you handle any exceptions that are raised in your code

yourself, they’ll be caught by the debugger. If you’re not running the code within

Visual Web Developer, the exceptions will be caught by the ASP.NET runtime,

which displays the errors in the browser.

Additionally, C# and VB enable you to handle runtime errors using the

Try-Catch-Finally construct.

The basic syntax of Try-Catch-Finally is as follows:

Visual Basic

Try

' Code that could generate the exception that you want to handle

213

Handling Exceptions Locally

Catch ex As Exception

' Code that is executed when an exception is generated

' The exception's details are accessible through the ex object

Finally

' Code that is guaranteed to execute at the end, no matter if

' an exception occurred

End Try

The equivalent C# syntax looks like this:

C#

try

{

// Code that could generate the exception that you want to

// handle

}

catch (Exception ex)

{

// Code that is executed when an exception is generated

// The exception's details are accessible through the ex

// object

}

finally

{

// Code that is guaranteed to execute at the end, no matter

// if an exception occurred

}

As a basic rule of thumb, we’ll place inside the Try block any code that we suspect

might generate errors that we’ll want to handle. If an exception is generated, the

code in the Catch block will be executed. If the code in the Try block doesn’t

generate any exceptions, the code in the Catch block won’t execute. In the end,

whether an exception occurred or not, the code in the Finally block will execute.

That’s an important point: the code in the Finally block will always execute, no

matter what! As such, it’s good practice to place any “mission-critical” code in

that block. For example, if database operations are performed in the Try block,

a good practice would be to close the database connection in the Finally block

to ensure that no open connections remain active on the database server—con-

suming resources!—or to keep database objects locked.

Exceptions propagate from the point at which they were raised up through the

call stack of your program. The call stack is the list of methods that are being

executed. So, if method A calls a method B, which in turn calls method C, the call

stack will be formed of these three methods, as Figure 5.56 illustrates.

214

Chapter 5: Building Web Applications