In which layer should logging of SQL exceptions occur?

Let's pretend for a moment that I have an application which has the following layers: a UI, Controller, Business Logic, and Data Access layer. The UI talks to the Controller, the Controller talks to the Business Logic, and the Business Logic talks to the Data Access layer. Let's also pretend I have a table in the database that houses error messages and exceptions that the administrator can use to troubleshoot problems with the application.

If a SQL exception is thrown in the Data Access Layer (e.g. there is a network issue, string would be truncated, etc.), how far up should the exception information make it before being logged? Ideally the log would contain messages from various layers that would give enough information for a developer to track down the issue. Is it OK for a SQL exception in the Data Access layer to get tossed all the way up to the UI and logged there? Or should it be caught locally, logged, and either rethrown or wrapped in another custom exception? Or should the Data Access layer return a special type that has a flag indicating whether there was an issue, and if so, it also attaches exception information. Also, is it a security concern for S开发者_如何学运维QL exception/stack trace information to make it as far as the UI?

I realize this might be a little subjective for a questions but I'm curious as to what the experts say. Please let me know if you need clarification.

No exception should escape out of the service layer. If you remove the UI, wouldn't you want the services to still be functional?

This also makes sense because it's easy to put your logging into aspects and apply them declaratively to the service interfaces.

You can wrap and rethrow if the custom exception adds value.