I am talking based on experience with Java and C#. I do not know if other language have different exception handling implementation.In order to achieve loose coupling, we need our code being programmed to use abstraction rather than implementation. However the exception handling case is the opposite. The best practice is you need to handle specific exception type (SqlException, StackOverflowException, etc).This thing may be better (or not) in java thanks for it's Checked Exception, there is a kind of contract between the interface and the consumer. But in C# or for the Unchecked Exception there is no contract about what exception can be thrown by the interface.For example, say that we use Repository Pattern to decouple the DAL with BLL. The simple catch exception usually be used like:public void Consume(){    try{        productRepository.Get(k=>k.Id == 0001);    }    catch(Exception e){        // handle    }}In more specific case we usually use SqlException. However it means that we must know that the ProductRepository is a repository to database server. What if the implementation changed to use file repository instead? Now you need to catch FileNotFoundException or something like that.Why does it violates the code to abstraction principle? And what can we do to prevent it?
Does Exception Handling Violates Program to Abstraction?
object oriented;exceptions;abstraction;separation of concerns
You should handle a specific case where it's appropriate to handle that specific case.In your example, the consumer is not the appropriate abstraction level to handle a SqlException, as you've surmised.The repository itself, which knows it is retrieving from a database, should be what handles the SqlException, perhaps repackaging it into a more application-specific and custom DataAccessException that can then be handled appropriately by the consumer.If you change the repository implementation to pull data from, say, a web service, that repository can handle an HttpException and repackage it into the DataAccessException. Or an XML repository can handle XML-specific exceptions and repackage them. And so forth.