When an error occurs you should not attempt to catch it or log it directly in your application's code unless it is an error you can hope to recover from. For example, if you have a data-driven web application and the database is offline, that is not something you can recover from. But if you are sending an email and have two email servers and the first one is down, you might be able to recover by using the second email server.
I've seen many ASP.NET applications where developers have used try...catch blocks to "swallow" errors. In reality, try...catch blocks only be used when there is a known recover strategy in the event of an error (such as using an alternate email server in my earlier example). If you have more than a handful of try...catch blocks in your application you're probably doing it wrong.
The reason you want to avoid overusing try...catch blocks is because you want your error logging and notification to be orthogonal to your application. You don't want to have to cut and paste error logging code in each page or component. Rather, you want to add some mechanism so that any unhandled exception is automatically logged and developers are automatically notified.
The good news is that such error logging and notification functionality is quite easy to implement. My preference is to use ELMAH, a free, open-source error logging and notification system. Alternatively, you can use ASP.NET's built-in error logging system, Health Monitoring.
For more information on ELMAH and Health Monitoring, as well as for guidance on custom error pages and setting everything up, see my article, Exception Handling Advice for ASP.NET Web Applications.
Happy Programming!
