Beginning ASP.NET 4.5 in CSharp and VB Opsylum

682 x CHAPTER 18 EXCEPTION HANDLING, DEBUGGING, AND TRACING
myMessage.From = New MailAddress(toAddress)
myMessage.To.Add(New MailAddress(fromAddress))
C#
string fromAddress = "you@example.com";
string toAddress = EmailAddress.Text;
myMessage.From = new MailAddress(toAddress);
myMessage.To.Add(new MailAddress(fromAddress));
Although it’s easy to see what the problem is in this example (the To and From addresses are mixed
up), it may be harder to find in a file with 250 lines of code. Additionally, because the compiler happily
accepts your mistake, you won’t notice the error until you see a message in your Inbox that you
thought you sent to your visitors.
The best way to track down and solve logic errors is using the built-in debugging capabilities of VS.
You get an in-depth look at these tools later in the chapter.
Runtime Errors
Runtime errors occur at run time, which makes them incredibly difficult to track. Imagine you have
a site that contains a bug that’s hidden somewhere in a page. You haven’t found it yet, but one of
your visitors did and she gets a nasty error message (more on those later) instead. What can you
do? Probably not much, because there’s a fair chance your visitor won’t even inform you about the
mistake.
So, it’s important to have a good error handling strategy in place that enables you to avoid errors
when possible, and that handles them gracefully and optionally logs relevant information for you
when they occur.
The following section deals with detecting and handling errors, or exceptions in .NET parlance;
later in this chapter, you learn how to log errors and shield your users from ugly pages with detailed
exception messages.
Catching and Handling Exceptions
Normally, when serious exceptions occur, the user is presented with an error message. For example,
if you try to send a message to a mail server that isn’t up and running, or doesn’t allow you to connect
to it, you’ll get an exception that provides details about the error. The exception that you get
is an instance of a class that ultimately inherits the System.Exception class; the base class for all
exceptions. Many exception types exist, each serving a distinct purpose.
By default, this exception bubbles up all the way to the user interface where it’s presented as a socalled
Yellow Screen of Death, a reference to Windows’ "Blue Screen of Death” that you get when
Windows crashes. You see a real example of this error in the next exercise.
Obviously, it’s a lot better if you can anticipate the exception and write some code that prevents it
from appearing in the user interface. You could, for example, display a nicely formatted message to
users instead, informing them the message could not be sent at this moment.
Fortunately, support for these kinds of scenarios is integrated deeply in the .NET programming
languages such as C# and Visual Basic .NET. In these languages, you can make use of Try Catch
Finally blocks (try catch finally in C#) where code that could potentially throw an exception