Refactor Code

Exception Handling In BAL and DAL
by adeel.alvi on 5/4/2008 9:04:30 PM
I usually donot handle exception in DAL but only in BAL. Currently I put my BAL method with Try, catch .have a look for refactor
// Some BAL Methods

public DataTable GetCustomerByAreaId(long areaId)
{

try
{
CustomerDAL objCustomer=new CustomerDAL();

objCustomerDataTable= objCutomer.GetCustomerByAreaId(areaId);

}
catch(Exception ee)
{
return new DataTable();
}

return objCustomerDataTable;
}
Refactor it!

why return an empty datatable here? if I were using your BAL to write a page, and I got an empty datatable as a result, I would assume that the area had no customers. This would cause a lot of unnecessary debugging to find the real issue. The exception isn't logged, and I have no real indication that an error occurred. Only handle these exceptions if you plan on doing something meaningful, such as handling it & supressing it, or adding additional information that would aid the consumer.
by subdigital on 5/4/2008 9:17:54 PM

how user should be notified in case of error as you mentioned , instead of empty datatable what should be done in catch , after loging exceptions.
by adeel.alvi on 5/4/2008 10:05:27 PM

To show an error i would return null instead of an empty datatable. If there is an emtpy datatable, i would also assume that there are no customers. You can check the result, if it is equal to null. So you can differ an error from an emtpy resultset.
by Baldi on 5/4/2008 11:21:12 PM

The majority of your BAL code wouldn't have a try/catch around it. Throw exceptions. Fail fast. It's the UI's job to handle errors. The only time you should be try'ing code is if you need to cleanup in the case of failure (like a connection or transaction) or if you can REALLY handle the error, or if you want to provide extra information. Returning null or an empty datatable just perpetuates the problem and causes errors to happen downstream, rather than where they originated.
by subdigital on 5/5/2008 7:24:41 AM

Sometime back I wrote a blog entry in which I demonstrated catching errors in Application_Error event. Check it out. http://aspadvice.com/blogs/azamsharp/archive/2007/10/25/Making-Your-Error-Pages-Pretty_2100_.aspx
by azamsharp on 5/5/2008 9:11:47 PM

You should all get a notification of this reply!
by azamsharp on 5/6/2008 6:57:01 AM

I normally access the BAL directly from the UI. So if you wouldn't have some try catch arround a method in the BAL or DAL you have to catch the excpetion every time you use BAL method. So you have to catch several times the same exception, which is quiet annoying. Something like connections (to SQL Server or whatever) problems you will always have to expect. So you put every time a try catch arround a method call in the UI to handle possible connection problems?
by Baldi on 5/6/2008 7:59:34 AM

Hey Baldi, I am not sure how it happened but when you posted this reply. The LoginView control updated and told me "You are logged in as Baldi". That was weird since I am logged in as AzamSharp. Wondering if you faced the same issues on your side.
by azamsharp on 5/6/2008 8:02:36 AM

:) No i don't have the same issue, i'm still logged in as baldi.
by Baldi on 5/6/2008 8:09:59 AM

In your case the UI would still have to check for null, which is error handling. What I'm saying is that it's probably not valid to continue if you got a database connection failure. Fail hard, fail fast. It's the UI's job to deal with possible errors from an API.
by subdigital on 5/6/2008 8:22:37 AM

I agree with subdigital. I have Enterprise Library handling exceptions, which logs and notifies support depending on severity. My UI is then responsible for showing a 'friendly' error message and the option of providing additional feedback to support.
by MrBretticus on 5/6/2008 7:52:12 PM

MrBretticus Can you share some of your example , to elaborate
by adeel.alvi on 5/6/2008 8:34:15 PM

Please log in to refactor the code! Login