locked
Exception Layer in n-tier architecture RRS feed

  • Question

  • User675201716 posted

    Hi..

         I'm developing a n-tier architecture... I'm confused with handling exception in the layers... Is it a good practise to add a Exception Layer to the architecture...

    Thanks in Advance...

     

    Thursday, May 13, 2010 4:17 AM

Answers

  • User377791177 posted

    Exception handling is costly from .NET framework point of view, Raising and handling an exception consumes considerable amount of memory resources, so , wrapping everything inside a try catch is definitely not a good scheme. But, at the same time creating an exeption layer does give beauty+readability to your application, i've seen frameworks where the structure was something like

    ExceptionBase (base class)

    TechnicalException BusinessProcessException DataLayerException MiscellaneousException

    Then the developer was supposed to derive from individual Exception classes in corresponding module, for e.g. in businesslayer while writing functions if the user violates a particular business rule then the corresponding exception was raised

    try

    {

    //do something

    }

    catch(SomeBusinessRuleViolatedException ex) //SomeBusinessRuleViolatedException:BusinessProcessException

    {


    }

    catch(SomeOtherBusinessRuleViolatedException ex)

    {

     

    }


    catch(StringLengthLessThanRequiredTechnicalException ex) //StringLengthLessThanRequiredTechnicalException:TechynicalException

    {

     

    }

    Although this way error handling totally became exception based which was definitely not good from performance point of view, but considering that it was an intranet application with not a very huge userbase we went after it. but it definitely gave a good readability to the application.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, May 13, 2010 5:11 AM

All replies

  • User377791177 posted

    Exception handling is costly from .NET framework point of view, Raising and handling an exception consumes considerable amount of memory resources, so , wrapping everything inside a try catch is definitely not a good scheme. But, at the same time creating an exeption layer does give beauty+readability to your application, i've seen frameworks where the structure was something like

    ExceptionBase (base class)

    TechnicalException BusinessProcessException DataLayerException MiscellaneousException

    Then the developer was supposed to derive from individual Exception classes in corresponding module, for e.g. in businesslayer while writing functions if the user violates a particular business rule then the corresponding exception was raised

    try

    {

    //do something

    }

    catch(SomeBusinessRuleViolatedException ex) //SomeBusinessRuleViolatedException:BusinessProcessException

    {


    }

    catch(SomeOtherBusinessRuleViolatedException ex)

    {

     

    }


    catch(StringLengthLessThanRequiredTechnicalException ex) //StringLengthLessThanRequiredTechnicalException:TechynicalException

    {

     

    }

    Although this way error handling totally became exception based which was definitely not good from performance point of view, but considering that it was an intranet application with not a very huge userbase we went after it. but it definitely gave a good readability to the application.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, May 13, 2010 5:11 AM
  • User1684693608 posted

    In most projects i worked in we used the following mechanism:

    • Handle the exception and log it in the data access layer
    • Handle the exception and log it in the business layer
    • Display the exception to the user in fireindly error messages in the presentation layer UI

    Hope this helps you in your case.

    Thursday, May 13, 2010 5:12 AM
  • User-952121411 posted

    The application and business process may require a different level of exception logging and information based on the type of application you are designing.  In many instances allowing exceptions to bubble up regardless of the layer to the highest level and then logging, handling, etc is acceptable for a majority of the situations.  You can implement a custom exception wrapper instead that is accessible by the layers to have some consistency in how exception are managed if you need a more detailed approach.  You could also implement a custom exception wrapper at the highest level only as well for specific exception handling requirements.

    Now the advice above is mostly in regards to exception logging, displaying, etc.  You obviously can attempt to handle specific exception within a layer if you can actually do something with them.  For example if you want to catch a specific SQLException and do something meaningful that will help the process continue as dictated by your requirements by all means that is fine as well. 

    Exception handling is one of the most vague and multi-opinionated areas of .NET I read about.  There really is no 'best' way of exception handling, but rather several good methods of handling exceptions so at a minimum the client is not displayed a hard exception to the browser.

    Thursday, May 13, 2010 5:08 PM