“The purpose of reviewing the Error Handling code is to assure that the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs.” (OWASP, 2011)
No Error Handling The absence of error handling is still a form of error handling. Based on the code in Figure 1, if an error occurred and was not handled within either the ReadXml or BuildRequest methods the error would bubble up to the Search method. Since this method does not handle any acceptations the error will then bubble up the stack trace. If this continues and the error is not handled within the application then the environment in which the application is running will notify the user running the application that an error occurred based on what type of application.
Figure 1: No Error Handling
public DataSet Search(string searchTerm, int resultCount)
{
DataSet dt = new DataSet();
dt.ReadXml(BuildRequest(searchTerm, resultCount));
return dt;
}
Generic Error Handling One simple way to add error handling is to catch all errors by default. If you examine the code in Figure 2, you will see a try-catch block.
On April 6th 2010 Louis Lazaris clearly describes a Try Catch statement by defining both the Try and Catch aspects of the statement.
“The try portion is where you would put any code that might throw an error. In other words, all significant code should go in the try section. The catch section will also hold code, but that section is not vital to the running of the application. So, if you removed the try-catch statement altogether, the section of code inside the try part would still be the same, but all the code inside the catch would be removed.” (Lazaris, 2010)
He also states that all errors that occur in the try section cause it to stops the execution of the try section and redirects all execution to the catch section. The catch section receives an object containing information about the error that occurred so that they system can gracefully handle the error properly.
When errors occur they commonly log them in some form. This form could be an email, database entry, web service call, log file, or just an error massage displayed to the user. Depending on the error sometimes applications can recover, while others force an application to close.
Figure 2: Generic Error Handling
public DataSet Search(string searchTerm, int resultCount)
{
DataSet dt = new DataSet();
try
{
dt.ReadXml(BuildRequest(searchTerm, resultCount));
}
catch (Exception ex)
{
// Handle all Exceptions
}
return dt;
}
Error Specific Error Handling Like the Generic Error Handling, Error Specific error handling allows for the catching of specific known errors that may occur. For example wrapping a try catch statement around a soap web service call would allow the application to handle any error that was generated by the soap web service. Now, if the systems wanted to send a message to the web service provider every time a soap error occurred but did not want to notify them if any other type of error occurred like a network time out issue. This would be varying tedious to accomplish using the General Error Handling methodology. This brings us to the use case for using the Error Specific error handling methodology.
The Error Specific Error handling methodology allows for the TryCatch statement to catch various types of errors depending on the type of error that occurred. In Figure 3, the code attempts to handle DataException differently compared to how it potentially handles all other errors. This allows for specific error handling for each type of known error, and still allows for error handling of any unknown error that my occur during the execution of the TryCatch statement.
Figure 5: Error Specific Error Handling
public DataSet Search(string searchTerm, int resultCount)
{
DataSet dt = new DataSet();
try
{
dt.ReadXml(BuildRequest(searchTerm, resultCount));
}
catch (TimeoutException ex)
{
// Handle Timeout TimeoutException Only
}
catch (Exception)
{
// Handle all Exceptions
}
return dt;
}
