Is your app trying to tell you something?

Exceptions (unexpected errors) are a part of every application lifecycle. No matter how reliable your code is there will be instances when the app will run into unexpected runtime issues and rightfully so the CLR will raise an exception. A general rule of thumb while handling exceptions is to only handle them if you can do something about it otherwise let it bubble up the call stack. This also minimizes on the number of try/catch blocks in your code.

A standard practice is to log all the errors to a destination of choice e.g. text files, emails or DB. There are exception handling/logging frameworks e.g.  the Exception Handling Application Block and ELMAH out there that offer this functionality. Once exceptions get logged then anyone is able to review them and take actions appropriately. However, if you have a large user base or provide SaaS (software as a service) then it maybe worthwhile to have them end up in a DB where you maybe able to do a little more than simply viewing them e.g. searching & reporting.

Exceptions can be like health indicators for your apps. Once you have access to your exception data in a format that can be queried then you maybe able to see patterns overtime which can provide insight into different aspects of your code e.g. does a certain error occur frequently due to a certain environment aspect that may have been overlooked in code?

An important thing to keep in mind is that throwing exceptions is an expensive process. For every exception that the CLR encounters it needs to walk the stack in search of an exception handler. So while it may not be easy sometimes to resolve certain exceptions in a simple manner but that maybe a cost you are willing to pay for a healthier app and better user experience.