Question

I am building a Data Access Layer which is going to be used in two types of applications.

1. Applications that do not care about the specifics of the error. If an exception occurs then most probably is going to just get logged and the user may not be aware of it.

   Example: Simple barcode stock taking application. The user inputs the barcode and if a connection is available to the database, then the system provides some extra info, if not then only the barcode is recorded locally. In this case I do not want detail exception handling.

2. Applications where I care a lot about the details of the exception.

What strategy do I have to follow when building my DAL in order to accommodate both categories?

Right now I am building an application from the first category and all I have done in my DAL methods is to just let the exception bubble up to the presentation layer, where I have several try..catch blocks in order to make the simple handling of logging, letting the user be unaware of he error.

Answer 1

Error handling is geting information from the part of code that knows to the person who needs to know. The DAL knows how to pritty print the trace of, say, a SqlException, SqlCommand and the SqlParameters collection. But the UI knows the entire call stack that caused the exception. The user probably doesn’t know what to do with the information, so you should log to a separate channel, such as email to the developer or a log in the database.

I would also recommend using a real application (or several real applications) as tests of your library if you are writting an error logger. For example, you could wire up your error logger to a variety of apps on codeplex and see what the pain points are in troubleshooting bugs, or try dogfooding and using your error logger to log errors is your own library.