Defensive Programming in Microsoft C# .NET
The Microsoft .NET framework introduced many great concepts for managed code. However, it is still up to the developer to understand that their code is only as good as a worst-case scenario. Defensive programming is a paradigm for developing with the understanding that code can fail at any point. Therefore the code must be able to intuitively address any scenario without having to rely on the expensive exception-handling engine.
Defensive programming is about protecting yourself from being hurt by something dangerous (If bad data is sent to a routine, it will not hurt the routine). By writing code that will protect yourself from bad data, unexpected events, and other programmers mistakes, will in most case reduce bugs and create a high quality software.
Good programmers will not let bad data through. It’s important to validate input parameters to not let the garbage in. It’s also important to make sure that if garbage does come in, noting will goes out or an exception will be thrown. The following C# .NET example is a result from defensive driven programming:
public Customer GetCustomerByName(string customerName)
{
var result = default(Customer);
//validate so no garbage is getting through
if (String.IsNullOrEmpty(customerName))
throw new ArgumentException("The name of the customer is empty");
try
{
//Get customer from data source
Customer customer = ...
if (customer == null)
//For security, never expose what TYPE of data source you are using
throw new ApplicationException(
"Error retrieving customer data from data source");
if (String.Compare(customer.CustomerName, customerName) == 0)
result = customer;
else
result = null;
}
catch (Exception ex)
{
//Perform logging
throw;
}
return result;
}
In the code above the input argument is first validated, if the validation failed, an exception is thrown. If the validation passes, the routine will try to get a customer from a data source by using the value from the customerName argument. If the customer was not found, nothing will out (returns null). If the routine fails to get the customer from the data source an exception will be thrown. In the example, correctness is more important than robustness. If robustness was more important, we could return an instance of an empty customer or “introducing Null object“ [Martin Fowler].
It’s important to both validate the input data, data returned from a data source and also use error handling to make sure a routine will not return any bad data if it fails. If the try and catch block are used, make sure an exception is passed on (thrown) and not only be catch within the catch block and then ignored, it could make the code more robustness but will violet correctness.
When using a defensive driven programming too much, it could create problems. Too much validation codes could make the code less readable and affect performance, so don’t overuse defense driven programming. Defensive programming will make error easier to find, easier to fix, and less damage to production code. The result of using defense driven programming will in return increase the quality of the software.
For more information:
http://weblogs.asp.net/fredriknormen/archive/2007/11/28/defensive-programming-and-design-by-contract-on-a-routine-level.aspx
Friday, April 02, 2010 12:54:00 PM