locked
a basic question on using DAAB in data access layer ? plz guide me RRS feed

  • Question

  • Hi,

    thanks for your attention and time.

    I am using DAAB to fill business objects (custom objects/ DTO) using IDataReader. Of course return type of function is custom object type.

    Now there can be 3 possibilities (please just consider stored procedure will return only one record)

    1) stored procedure return a record
    2) stored procedure do not find a record
    3) there accrue an error

    Suppose function's return type is customer, if data found I will receive a object of  customer, if no record found I will get null but how to know on use interface if there would be some error ? I am using try catch blocks but in case of error what should be return to indicate on user interface that there was some error while fetching data from db ?

    Please guide me.

    thanks in anticipation for sharing and guding,

    Haansi<input id="gwProxy" type="hidden"><!-- Session data--></input> <input id="jsProxy" onclick="jsCall();" type="hidden" />
    Monday, February 1, 2010 2:20 PM

Answers

  • I would suggest either removing the Try/Catch blocks and allowing the error to propogate to the UI.

    OR

    Catch the error, define a new error, and throw the error to the UI.

    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!
    • Proposed as answer by DeborahKMVP Thursday, February 4, 2010 8:25 PM
    • Unproposed as answer by Haansi Friday, February 5, 2010 3:41 AM
    • Marked as answer by Haansi Friday, February 5, 2010 3:41 AM
    Monday, February 1, 2010 4:21 PM
  • Agreed, if you hit an error in the DB you can just let the exception bubble up to the UI and present it in some nice way to the user after maybe logging it to a file (in the case of db errors where you obviously can't write to a database logging table).

    Unless you are going to handle the error in the DAL then there is no point in trapping it at all there.
    • Marked as answer by Haansi Friday, February 5, 2010 3:40 AM
    Wednesday, February 3, 2010 11:15 PM

All replies

  • I would suggest either removing the Try/Catch blocks and allowing the error to propogate to the UI.

    OR

    Catch the error, define a new error, and throw the error to the UI.

    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!
    • Proposed as answer by DeborahKMVP Thursday, February 4, 2010 8:25 PM
    • Unproposed as answer by Haansi Friday, February 5, 2010 3:41 AM
    • Marked as answer by Haansi Friday, February 5, 2010 3:41 AM
    Monday, February 1, 2010 4:21 PM
  • Agreed, if you hit an error in the DB you can just let the exception bubble up to the UI and present it in some nice way to the user after maybe logging it to a file (in the case of db errors where you obviously can't write to a database logging table).

    Unless you are going to handle the error in the DAL then there is no point in trapping it at all there.
    • Marked as answer by Haansi Friday, February 5, 2010 3:40 AM
    Wednesday, February 3, 2010 11:15 PM
  • Thanks buddies for your precious time and guidance. so nice of you


    haansi
    Friday, February 5, 2010 3:41 AM