Question

If I am correct then the idea behind having an interface for data access objects is that the actual store, whether it is database, file, or XML is hidden from the client code. But if you are using SqlCommand and SqlConnections and something goes wrong and it throws a SqlException, then the client code becomes aware of the implementation and the fact that we are using a MS Sql server as the database. So we can change the client code to catch DbException. But then we are making the client aware of the implementation. So this seems like a leaky implementation to me.

I think the correct approach would be to wrap into custom DAL exceptions which the client code could respond to. It just seems like a lot of work to do when

1. The database is unlikely to change.
2. The store type (database, file, xml) is even more unlikely to change.

In this scenario should the client code just handle the SqlException itself. The client code is more closely coupled but I honestly don’t see it changing. Or is it still worth wrapping the exceptions?

Answer 1

If you are talking about persistence ignorance (and wish to retain it), then correct, you shouldn’t let SQL Exceptions bubble up as they are.

You should create your own specific exception types and in your implementation wrap any exception with your custom exception (PeristenceExcpetion?) as an InnerException.

Having said that, if you know that you are not changing your store type and database, then there is little reason to decouple the exceptions.