locked
best practice on error handling RRS feed

  • Question

  • User2027942032 posted

     Hi,

    would anyone recommend the best pratice to implement error handling in Business logic? thx

    Thursday, January 14, 2010 6:12 PM

Answers

  • User-952121411 posted

    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, etc.).

    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! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 20, 2010 10:19 AM

All replies

  • User1563021683 posted

    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 

    Tuesday, January 19, 2010 8:46 AM
  • User2027942032 posted

     

    Not sure about Error Handling module in the Enterprise Library.. please explain 

    Tuesday, January 19, 2010 7:04 PM
  • User-952121411 posted

    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, etc.).

    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! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 20, 2010 10:19 AM