locked
Exception Management RRS feed

  • Question

  • Hi all,

    I am sure this is pretty trivial for many... but wanted to get a take on architectural design for exception management/logging.

    Background

    Say I have a 3 layer application - UI, Business Logic and Data Access.  What is the ideal exception handling practice in following scenarios:

    Questions

    Exceptions in Data Access layer

    • Should I handle any exceptions at this level or complete ignore them (no exception handling blocks)?
    • If I should handle then do I simple re-throw or log and re-throw.
    • If I log and re-throw then does the upper level (Business Logic) log and re-throw the same again!

    Exceptions in Business Layer

    • Do I log and suppress or log and re-throw?
    • Should I differentiate between exceptions originating from this layer as opposed to lower level layer specially to make a decision on last point.

     

    Thanks for your advice in advance.

     

     

    Thursday, July 15, 2010 6:32 PM

All replies

  • I only catch exceptions in the data access layer if:

    • I have some additional information there that I want to include in the logging. I then log and rethrow.
    • I am going to do something to handle the error (create a missing table, for example). Then I handle the error and continue.
    • The error can be ignored. Then I just continue.

    I only catch exceptions in the business layer for the same reasons.

    Otherwise, the majority of the error catching/logging is in the UI where you have the facility to notify the user of the problem and close gracefully.

    Hope this helps.


    www.insteptech.com ; msmvps.com/blogs/deborahk
    We are volunteers and ask only that if we are able to help you, that you mark our reply as your answer. THANKS!
    Thursday, July 15, 2010 6:52 PM
  • The general rule of thumb I follow is to only catch exceptions if you actually plan on doing something with them.  There are a few "patterns" that I tend to follow, depending on the type of project I am working on.  For example there is probably a difference between how you would go about exception handling in a n-tier (services based) applications as opposed to in process n-layer applications.  If it's a n-layer (everything in one process) application, I often catch exceptions in my DAO/repository methods, log them, and throw a common (home made) DatabaseException back up.  In most cases the business layer will not handle this and allow it to go back up to the UI.  In some cases, if there is retry logic as per business requirements I might catch this in the business layer and attempt to retry the database operation.  The idea behind this is that the higher levels shouldn't always have all the details of what has happened, only enough to know how to respond to it.  For example the UI shouldn't care that a parameter to a stored proc is null, but it should know that there is a database exception.

    In n-tier applications things could go many different ways, I tend to avoid throwing SOAP exceptions, this means that my contracts have some sort of error handling data structures baked into them.  So I would have to introduce some sort of mapping of exceptions to the contract in the service layer.

    Thursday, July 15, 2010 7:25 PM
  • It depends on what you want to do with the exception.

    In business application, these are common actions in catch:

    • Collect more helpful context infomations for tracking error more easily. (optional)
    • Shaping the infomation as necessary (optional)
    • Logging the infomation
    • If the error should be notified to user, convert it to some custom-special exceptions or DTO with more user-friendly message(optional). Otherwise, just ignore it.

    If above actions are enough, there is no reason to write error handler. You could just ignore and let it rethrowed automatically. And you can handle it in global exception hander as unhandled exception. (for example, you can utilize global.asax in ASP.NET Web app.)

    However, there are some cases requires more than common actions. For example, in some business scenario you need to compensate the failure, retry the actions using queue, etc. That cannot be done in global exception handler, and should be handled by own handler.

    Friday, July 16, 2010 8:42 AM