User Input Validation, Error Messages, and Error Processing
The error handling process begins and ends in the ASP.NET code-behind page (Figure 1): E.g., the page is Default.aspx and the code-behind pages is Default.aspx.cs. Notice that the process begins with the client input, and Microsoft of JavaScript validators handle the first line of exception managment. This prevents unnecessary round-trip postbacks to refresh page data from view state information sent back from the IIS server. This is covered in more detail in the Input Validation section.
A try-catch block in the code-behind wraps the button-click save if the data is updated or inserted from a form button event. If the data is saved from an HTML onclick event through AJAX, then consider a custom JavaScript client validator with error message feedback from an alert message box. With an ASP.NET callback, client side validators can still handle first line data validation wrapped in a try-catch block. In all these cases, however, the secondary data validation is handled in the domain BLL passed from the form
The data is then sent to the domain Data Access Layer (DAL) to insert, update, or delete database information. If an error occurs in the DAL, BLL, or page code-behind the catch block reports the SQL Server or general exception a an error logginging service (See Figure 2 below).
Figure 1: The Exception Management Process Overview
Logging all the code-behind, BLL, DAL, or database exceptions that arise in the application should be strictly for internal use only. Users should see only a friendly error message that informs them of the error in a general, but non-specific way. They should also be told to contact the appropriate person to report the error if the problems persist. The techical error detail is logged to a database, or if the database is down, the error is logged to an XML file or some other specified location (e.g., the server log).
Figure 2: The Error Logging Service
The Catch part of the Try-Catch block would look something like this:
catch (SqlException sqlEx) //The SQL Server specific errors from the DAL{
//Add Error Service Logging after debugging
//LogError is an error object to be sent to a separate server that hosts a WCF HTTP or TCP service
LogError logError = new LogError();
//The LogError properties are assigned from Web.config or Application Session Variables logError.ApplicationID = Convert.ToInt32(ConfigurationSettings.AppSettings["AppKey"]); ; logError.UserID = Session["MP_UserID"].ToString(); logError.Module = "CAM_Administration_Users.Page_Load()"; logError.Description = sqlEx.Message;
//The LogServerError is the Error Service Reference object set up from the WSDL Service Reference in
//the Visual Studio 2008 project. The application variable contains the error logger endpoint name. This
//could be HTTP or TCP binding.
LogServiceError(logError, Application["ERRORLOGGER_ENDPOINT_NAME"].ToString());
//The user gets a non-specific error message to preserve secure processing. ShowMessageBox(this, "An error has occurred accessing the database. Please contact your supervisor.");}
catch (Exception ex) //The BLL, Code-behind, or other error catch block{
//Call error service to log error
LogError logError = new LogError(); logError.ApplicationID = Convert.ToInt32(ConfigurationSettings.AppSettings["AppKey"]); ; logError.UserID = Session["MP_UserID"].ToString(); logError.Module = "CAM_Administration_Users.Page_Load()"; logError.Description = ex.Message;
LogServiceError(logError, Application["ERRORLOGGER_ENDPOINT_NAME"].ToString()); ShowMessageBox(this, "An error has occurred accessing the database. Please contact your supervisor.");}