ASP.NET 3.5 Enterprise Application Development with Visual Studio® 2008: Problem - Design - Solution

Chapter 5. Exception Handling

Have you ever taken over an application for another developer and been asked to track down a problem only to find that an exception was being thrown by the code but the previous developer was ignoring it? I've seen this happen plenty of times. VB used to make it easy to cover up exceptions with the dreaded On Error Resume Next statement. This would tell the application to just keep on executing line after line even if an exception occurred. I've actually heard the excuse, "Well, if the system doesn't show the user the exception, the application will look more professional." Anyone with that type of mentality toward a system should be moved to technical support and they'll change their mind immediately. These are some of the toughest "bugs" to track down.

An exception is an error that occurs during execution. Sometimes there are known exceptions that the developer can handle, while other exceptions are unexpected. An example of a known exception would be when you try to write to a file and it is marked as read-only. You can trap this exception and give the user a friendly message to change the file's attributes. Unexpected exceptions are obviously different because you can't anticipate them, but you still need to make the user aware that something happened and the system didn't perform as expected. You would hope that users call the help desk to let someone know that a problem has occurred so you can fix it, but usually they won't. Even if they do, ...