locked
Help with DAL and BLL exception handling RRS feed

  • Question

  • User1100692814 posted

    Hi all

    I am working on an application at work. It implements a n-Tier, Provider and Repository Design Pattern architecture.

    I am just trying to work out how and when to handle any errors from the DAL ex: You call a method from the BLL Case.GetCaseByID(int Id), that in turn calls a DAL method by the same name. But, if a case the ID can not be found do I pass a return value back to my DAL and throw the error there or return null back to my BLL and let it happen there.

    I hope the below explains a little better. Thanks in advance

    Regards

    David

    BLL Method

    public bool CaseExists(int caseID)

    {

                 // Should I capture a null here if nothing is returned and throw a ProviderException or should this be handled at DAL level?

                 return PPC.DAL.ClinicalServices.CaseExists(int caseID);

    }


    DAL Method

    public bool CaseExists(int caseID)

    {

                using (SqlConnection cn = new SqlConnection(this.ConnectionString))
                {
                    SqlCommand cmd = new SqlCommand("proc_ClinicalServices_CaseExists", cn);
                    cmd.CommandTimeout = this.CommandTimeOut;
                    cmd.CommandType = CommandType.StoredProcedure;
                    cmd.Parameters.Add("@CaseID", SqlDbType.NVarChar).Value = caseID;
                    // cmd.Parameters.Add("@ReturnValue", SqlDbType.Int).Direction = ParameterDirection.ReturnValue; -- Should I rather return a value here and pass it to the BLL and catch the exception there?
                    cn.Open();
                    ExecuteNonQuery(cmd);
                    return (GetReturnValue(cmd)); // -- or return (true/false i.e. int ret = ExecuteNonQuery(cmd); return (ret ==1);
                }

    }

    Friday, June 4, 2010 4:30 AM

Answers

  • User-1507865547 posted

    Raising an exception and handling the exception has always a cost(performance) associated with it. IMHO, exception should be raised only if your code gets unexpected input, which can not be handled. I think, in your case, it is pure business validation. So, it should be handled silently.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 4, 2010 5:05 AM
  • User-84650026 posted

    DAL will be perfect place for handling any DAL exceptions. You should log them at DAL only, rest of the layers should just propogate error in the hierarchy. The exception should be handled as a DALException type and when displayed on UI it should be a user friendly message.

    If there is an exception in BLL it should be handled in BLL, logged in BLL with a BLLException type and propogated in hierarchy if needed to be displayed to user.

    System exceptions will not need to be propogated however a generic exception message will be required if it breaks functionality.   

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 4, 2010 5:30 AM

All replies

  • User-1507865547 posted

    Raising an exception and handling the exception has always a cost(performance) associated with it. IMHO, exception should be raised only if your code gets unexpected input, which can not be handled. I think, in your case, it is pure business validation. So, it should be handled silently.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 4, 2010 5:05 AM
  • User-84650026 posted

    DAL will be perfect place for handling any DAL exceptions. You should log them at DAL only, rest of the layers should just propogate error in the hierarchy. The exception should be handled as a DALException type and when displayed on UI it should be a user friendly message.

    If there is an exception in BLL it should be handled in BLL, logged in BLL with a BLLException type and propogated in hierarchy if needed to be displayed to user.

    System exceptions will not need to be propogated however a generic exception message will be required if it breaks functionality.   

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 4, 2010 5:30 AM