Managing Exceptions in .NET

http://www.codeguru.com/csharp/csharp/cs_syntax/errorhandling/article.php/c12971/

Basically, there is lot of difference between an error and an exception. As said, an exception should be a real exception. Most errors can be validated and controlled on the UI layer and need not to be carried to the business layer. Errors should be controlled and validated; they should not be converted to exceptions unless and until it is necessary to do so. 

For example, suppose you have a function called GetBillCyclePeriod(Customer cust) in your business logic. The UI sends the customer object. If the function receives the customer object as null, it is an error and not an exception. People code like this:

Public DateTime[] GetBillCyclePeriod(Customer cust)
{
if (cust == null)
{
throw new ArgumentNullException();
}
}

This is very bad practice because exceptions are very costly and, if not used properly, they harm performance. In fact, the example above is an error from the UI and should be validated on the UI itself. Some examples of exceptions can be that the database server is down, network is very slow, system crashes; these really are exceptions. In the coming sections, you will see how you can deal gracefully with the exceptions.

To build a successful, bug free, and stable application, you should design the exception handling architecture and strategy in a way that will help you maintain the application and fix any bugs by providing you with detailed information. (100% bug free is not possible. The code should at least be less prone to errors and errors should not recur.) The exception handling system should be able to perform the following tasks:

Detect an exception.

Log an exception.

Report an exception (by means of mail or something like that).