Errors that occur deep down in a data access layer or even higher up, (say within ADO.net operations for example) rarely make much sense to an end user. Simply bubbling these errors up to a UI and displaying them will usually achieve nothing except frustration for an end user.
I have recently employed a basic technique for reporting errors such as this whereby I catch the error and at least add some user friendly text so that at least the end user understands what failed.
To do this I am catching an exception within each specific function (say for example a fetch function in a data access layer), then raising a new error with user friendly text about the function that has failed and probably cause, but then embedding the original exception in the new exception as the ‘inner exception’ of that new exception.
This can then occur at each layer if necessary, each consumer of the lower level function adding it’s own context to the error message, so that what reaches the UI is an increasingly user friendly error message.
Once the error reaches the UI – if necessary – it can then iterate through the nested exceptions in order to display an error message that firstly tells the user which operation failed, but also provides a bit of technical information about what actually went wrong.
e.g.
‘The list of customer names your requested could not be displayed.’
‘Obtaining the list of customers you requested failed due to an error with the database.’
‘There was an error connecting to the database when retrieving a list of customers’
‘Login failed for user xx’
My question is this: Is this horribly inefficient (all those nested exceptions)? I suspect it is not best practice so what should I be doing to achieve the same thing – or should I in fact be trying to achieve something better?
It is just slightly horrible.
If you are showing an error to the end user, the user is supposed to be able to act about it. In ‘The list of customer names your requested could not be displayed.’ case, your user will just think ‘so what?’ On all of these cases, just display a ‘something bad happened’ message. You do not even need to catch these exceptions, when something goes bad, let some global method (like application_error) handle it and display a generic message. When you or your user can do something about the error, catch it and do the thing or notify the user.
But you will want to log every error that you do not handle.
By the way, displaying information about the errors occuring may yield to security vulnerabilities. The less the attackers know about your system, the less likely they will find ways to hack it (remember those messages like ‘Syntax error in sql statement: Select * From Users Where username=’a’; drp database;–‘…’ expected: ‘drop’ instead of ‘drp’. They do not make sites like these anymore).