Last post Jan 20, 2010 10:19 AM by atconway
Jan 14, 2010 06:12 PM|ronald_yoh|LINK
would anyone recommend the best pratice to implement error handling in Business logic? thx
Jan 14, 2010 07:49 PM|rivdiv|LINK
I don't know if this is considered the "best" but check these links out
Jan 19, 2010 08:46 AM|sujithgokul|LINK
Always have an error handling framework and call the error handling method of this framework from the business logic. You might checck the Error Handling module in the Enterprise Library
Jan 19, 2010 07:04 PM|ronald_yoh|LINK
Not sure about Error Handling module in the Enterprise Library.. please explain
Jan 20, 2010 10:19 AM|atconway|LINK
would anyone recommend the best practice to implement error handling in Business logic?
I think this answer is application and architecture specific. In many of my applications, I do not have the business logic do anything at all with the exception except allow it to bubble up automatically to allow the caller decide what to do with the exception.
In many cases, I just have the top most caller log and report the exception in the background, and decide if the exception was so bad that the user needs a soft landing on a custom error page.
The exception to this rule at the business logic layer is when I can take action based on the exception type and do something meaningful with it (i.e. timeout from server, so try to call again 1 more time, or date value error so use a default value instead,
You can create a framework or class that houses and wraps exception information as mentioned before which is the next step and another good idea. This way the business logic layer can expose the exception a custom object that contains more meaningful information
that you need specific to your application. Regardless of using a custom exception framework or a raw exception object, I still make the caller responsible for how to handle the issue. However, I still find that most often I do not have my business logic
deciding what to do with exceptions. I think that is the callers responsibility. To me the BLL should be a bit dumb in the sense that it says "You pass me data or tell me to do something and I will go do it based on the rules within me. Beyond that, I am
not going to make any decisions on what to do with exceptions unless I already explicitly have rules on how to handle them."
This is actually a bit analogous to .NET objects as well. Lets say you create a new DataSet and then try to access a table within the DataSet that does not exist. What happens? .NET does not say, "Well let me just go ahead and add another table
because the caller must have wanted it.". Instead it throws an exception back to you stating "Hey you did something wrong. It is up to you on how to handle it." I think that the business logic layer and business objects should act in a similar manner.
Overall these are not hard set rules. There are a gazillion articles on how to do exception handling best. They are probably all right in some way or another. I think at the end of the day the most important factor in exception handling is to make sure
that the exception does get handled and does not
bubble all the way back up to the client's screen with a hard error. Anything improving on this is a a good start on exception handling.
Hope this helps!