locked
Exception handling RRS feed

  • Question

  • Hi, i am trying to get how to use exception handling properly. Usign a 3 layer approach what is the best way to use exception handling.

    For example:

    DAL:

     public static Customer GetCustomerById(string id)
            {
                  ............code to connect...........
               Customer c = new Customer();

               return c;
            }

    BLL

     [WebMethod(Description="Get a Customer by their ID")]
        public DAL.Customer GetCustomerByID(string id)
        {
            return DAL.Customer.GetCustomerById(id);      
        }


    UI
    public void PopulatecustomerDetails()
    {
                s = new CustomerService.ServiceSoapClient();          
                CustomerService.Customer c = new CustomerService.Customer();


                c = s.GetCustomerByID(CustomerId);
                ..................
    }

    Thankx.
    Thursday, September 10, 2009 12:42 PM

Answers

  • It does depend somewhat on how your layers are distributed.

    DAL generally allows errors to flow out. If you're exposing via WCF or another remoting framework, then you have to explicitly allow your exceptions to propagate out. Alternatively, you can log locally and raise a generic exception to the calling code.

    I personally like to design BLL objects to capture and store errors. Definitely validation errors, but sometimes also backend errors (which are a different type of error completely).

    The UI then must be capable of displaying the BO's errors, and understand a BO in an error state.

           -Steve
    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
    MSBuild user? Try out the DynamicExecute task in the MSBuild Extension Pack source; it's currently in Beta so get your comments in!
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 2:49 AM
  • Well i guess its better if u do exception handling on Both BLL and UI. In your BLL u can catch DAL exceptions and can throw sophisticated error messages to your UI. E.g. Due to some reason, DAL gives exeption "Can not insert NULL in Primary Key field". Now if it is caught at UI only and printed as an error, a normal non-technical user wouldn't get the meaning of this message. But if u catch it on ur BL (and do some string matching for errors occured), you'd have a chance to be more sophisticated to that user. Moreover, UI has to implement exception handling for any exception in the inner layers, to be caught otherwise they may appear as unhandled to the user.


    So my summary is
    - Do no exception handling in DAL.
    - Do exception handling for DAL exceptions in BLL.
    - Do exception handling for all type of exceptions that could occur, in UI
    • Edited by Hassan Mehmood Friday, September 11, 2009 7:50 AM
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 7:15 AM
  • What i am doing in BLL is

        [WebMethod(EnableSession = true)]
        public string ProcessCommands()
        {
            try
            {
            }
            catch (OracleException oEx)
            {
                throw new Exception(oEx.Code.ToString(), oEx);
            }
        }

    I catch exception in my BLL [of what ever type as OracleException in this case] and in client side i simply catch The General Exception and get the particular error message/exception.

    Now its totally depend on your scenario
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 7:38 AM

All replies

  • It does depend somewhat on how your layers are distributed.

    DAL generally allows errors to flow out. If you're exposing via WCF or another remoting framework, then you have to explicitly allow your exceptions to propagate out. Alternatively, you can log locally and raise a generic exception to the calling code.

    I personally like to design BLL objects to capture and store errors. Definitely validation errors, but sometimes also backend errors (which are a different type of error completely).

    The UI then must be capable of displaying the BO's errors, and understand a BO in an error state.

           -Steve
    Programming blog: http://nitoprograms.blogspot.com/
      Including my TCP/IP .NET Sockets FAQ
    MSBuild user? Try out the DynamicExecute task in the MSBuild Extension Pack source; it's currently in Beta so get your comments in!
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 2:49 AM
  • Well i guess its better if u do exception handling on Both BLL and UI. In your BLL u can catch DAL exceptions and can throw sophisticated error messages to your UI. E.g. Due to some reason, DAL gives exeption "Can not insert NULL in Primary Key field". Now if it is caught at UI only and printed as an error, a normal non-technical user wouldn't get the meaning of this message. But if u catch it on ur BL (and do some string matching for errors occured), you'd have a chance to be more sophisticated to that user. Moreover, UI has to implement exception handling for any exception in the inner layers, to be caught otherwise they may appear as unhandled to the user.


    So my summary is
    - Do no exception handling in DAL.
    - Do exception handling for DAL exceptions in BLL.
    - Do exception handling for all type of exceptions that could occur, in UI
    • Edited by Hassan Mehmood Friday, September 11, 2009 7:50 AM
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 7:15 AM
  • What i am doing in BLL is

        [WebMethod(EnableSession = true)]
        public string ProcessCommands()
        {
            try
            {
            }
            catch (OracleException oEx)
            {
                throw new Exception(oEx.Code.ToString(), oEx);
            }
        }

    I catch exception in my BLL [of what ever type as OracleException in this case] and in client side i simply catch The General Exception and get the particular error message/exception.

    Now its totally depend on your scenario
    • Marked as answer by liurong luo Monday, September 14, 2009 12:10 PM
    Friday, September 11, 2009 7:38 AM