Before we get on with the article, a couple of quick announcements. Regular readers of this site know well my tendency to put this site through an obnoxious number of redesigns. Sometimes I feel like I'm in a never-ending design cycle, because I'm always tweaking something here or adding something there. Anyway, I once again found myself twitching to do a redesign. I hesitate to say that I got tired of the old ( well, current, as of this entry ) theme, because I still like it; however, it most definitely grew old. So: look for the new design soon — like over the weekend; definitely over next week. :-)
Moving on.
Catching Exceptions in a Method
public void DownloadPdf(string path)
{
try
{
System.IO.StreamReader reader = System.IO.File.OpenText(path);
}
catch (System.UnauthorizedAccessException ex)
{
// Hey, you don't have access to the file!
}
catch (System.IO.FileNotFoundException ex)
{
// Hey, the file doesn't exist
}
catch (Exception ex)
{
// Something bad happened
}
}
Catching Exceptions at the Page Level
protected override void OnError(EventArgs e)
{
Exception exception = HttpContext.Current.Server.GetLastError();
// Inform the user about the exception, log it, and do whatever
// else you want to do here.
}
Catching Exceptions at the Application Level
// In global.asax
protected void Application_Error(object sender, EventArgs e)
{
Exception ex = HttpContext.Current.Server.GetLastError();
// Do whatever with the exception here.
}
You might notice that catching exceptions at the application level is remarkably similar to catching them at the page level. This is good — one less thing for us to have to remember. :-)
Clearing Errors
What if you want to have your application continue on its merry way, not stop dead in its tracks because of the exception? For example, suppose the user is trying to upload a file and your application throws an exception because the file is too big. It would be nice if your application lets the user to continue working instead of taking him to the jarringly-ugly yellow page of death error page?
This is what happens when you catch an exception (aka, method 1), so you don't need to do anything special. However, it's a pain to have to wrap every single method in a try...catch block. The way to clear exceptions/errors with the other two methods is with the Server class' handy ClearError method:
// In global.asax
protected void Application_Error(object sender, EventArgs e)
{
Exception ex = HttpContext.Current.Server.GetLastError();
// Do whatever with the exception here.
HttpContext.Current.Server.ClearError();
}
Conclusion
You should, at some point, trap all exceptions that occur in your application. At the very least, you should redirect the user to a custom error page. Not only are the default error pages produced by ASP .NET horrendously ugly, they're usually unhelpful to the end-user. Also, they reveal information about your code, which is bad from a security-viewpoint. ASP .NET provides 3 very easy ways to trap errors in an application.
My favorite method — well, my second favorite method — of catching exceptions is using the Global.asax's Application_Error method. ( My favorite way is to use HttpModules, which I'm going to talk about in a future article. )
