Programming Microsoft ASP.NET 4 - Dino Esposito [145]
Exceptions in Action
To execute a piece of code with the certainty that any (or just some) exceptions it might raise will be caught, you use the following code:
try
{
// Your regular code here
...
}
catch
{
// Your recovery code for all exceptions
...
}
The sample code snippet can have a number of variations and extensions. You can add a finally block, which will finalize the operation and run regardless of whether the execution flow went through the try or the catch block. The snippet shown will catch any exceptions. Because of its extreme generality, you might need to lose some valuable information about what has happened. A better approach consists of listing one or more catch blocks, each trying to cache a specific exception:
try
{
// Your regular code here
...
}
catch(NullReferenceException nullReferenceException)
{
// Your recovery code for the exception
...
}
catch(ArgumentException argumentException)
{
// Your recovery code for the exception
...
}
finally
{
// Finalize here but DON'T throw exceptions from here
...
}
Exceptions will be listed from the most specific to the least specific. From a catch block, you are allowed to swallow the exception so that other topmost modules will never know about it. Alternatively, you can handle the situation gracefully and recover. Finally, you can do some work and then re-throw the same exception or arrange a new one with some extra or modified information in it.
The catch block is fairly expensive if your code gets into it. Therefore, you should use the catch block judiciously—only when really needed and without overcatching.
Guidelines for Exception Handling
When writing a module (including ASP.NET pages), you should never throw an exception as an instance of the System.Exception class. It is strictly recommended that you try to use built-in exception types such as InvalidOperationException, NullReferenceException, and ArgumentNullException whenever these types apply. You should resist the temptation of having your very own exceptions all the way through, although for program errors you should consider defining your own exceptions.
In general, you should be very specific with exceptions. ArgumentNullException is more specific than ArgumentException. An exception comes with a message, and the message must be targeted to developers and, ideally, localized.
Swallowing an exception is possible and supported, but you should consider that in this case some modules might never know what went wrong. This approach might not be acceptable in some cases, so use it with extreme care. In general, don’t be afraid to let exceptions propagate up the call stack.
When using exceptions, pay a lot of attention to cleanup code. The finally block serves exactly the purpose of ensuring that any cleanup code is always executed. Alternatively, when the cleanup code sees an object that implements IDisposable, you can resort to the using statement:
using(var someObject = new SomeDisposableObject())
{
// Code at risk of exceptions
...
}
If placed in a finally block, the cleanup code is always executed. This is an important guarantee because if an unexpected exception is thrown, you might lose your cleanup code.
Finally, here are a few recommendations for situation in which you get to write your own exception classes. For a long time, Microsoft said you should derive your exception classes from System.ApplicationException. More recently, there’s been a complete turnaround on this point: the new directive says the opposite. You should ignore ApplicationException and derive your exception classes from Exception or other more specific built-in classes. And don’t forget to make your exception classes serializable.
Basics of Page Error Handling
When an exception occurs in an ASP.NET application, the CLR tries to find a block of code willing to catch it. Exceptions walk