Exception Management Strategy for N-tier Applications - Part I

In this article, which is spread across two parts, I would like to discuss about how effectively exceptions can be managed Enterprise applications spread across N-Tiers.

In any application that uses Enterprise Architecture, managing exceptions forms a critical requirement. To build successful and flexible applications that can be maintained and supported easily, an appropriate exception management strategy must be adopted.

Now what are exceptions, by the way?

Exceptions represent a breach of an implicit assumption made within code.

For example, if your code tries to access a file that is assumed to exist, but the file is missing, an exception would be thrown. However, if your code does not assume that the file exists and checks for its presence first, this scenario would not necessarily generate an exception.

Microsoft Application Blocks are generally used for Enterprise Applications to manage Exceptions. The Application Blocks provide a set of APIs that can be directly used for managing exceptions. If your application is complex and spread across manylayers, we can build a custom application class that uses these Application Blocks for handling exceptions.

Now let us suppose we have the following layers in our Application:
1. Data Access Layer (DAL)
2. Business Layer (BL)
3. Business Facade Layer(BFL)
4. Presentation Layer (PL)

and with these layers, we also have class library that contains the Microsoft Application Blocks for Exception Management.

To this library we will add our custom Base Exception class say, MyAppBaseApplicationException class.
This MyAppBaseApplicationException class will inherit from BaseApplicationException that comes with the Exception Management Block. The following is the sample code that can be used for MyAppBaseException:


///

/// Summary description for MyAppBaseApplicationException.
///

public class MyAppBaseApplicationException:CognizantBaseAppException
{
#region Fieldsprivate int errorNumber; //The error number assigned by sql or by the .net framework
private string actionTaken; //The task being performed when the exception occurred
private string contextInfo; //A field to be used to get the context in which the exception occured
private bool exceptionHandled; //Indicates whether or not the exception has been handled
private bool displayToClient; //Indicates whether or not the end user should see the exception details.
private string logonUser; //The user of the system when the exception occurred.
private string exceptionDate; //The date and time when the exception occurred.
private bool isLogged;//Indicates if the exception is logged to SQL Server
private string mstrStackTrace;//For stack trace
#endregion //Private Data Members
#region Constructors

/// Constructor with exception id and inner exception
public MyAppBaseApplicationException(string message, Exception inner) : base(message,inner)
{
Initialize();
}
///Add other constructors if needed
#endregion

#region Properties
///Add properties to access the private members
#endregion

You may need to add additional properties pertaining to your application. The isLogged flag is important as it indicates if a specific exception has been logged or not. This is necessary when your Application is spread across many layers.

Having written the Base class, the next article will concentrate on how to use this MyAppBaseApplicationException class and how we log the exceptions in all the four layers.