Chapter 4: Handling Errors with Class

We have all been there. It is Friday afternoon, you have just released the application to the users, and within three hours you are already fielding phone calls from users because your application is popping up error messages. And what is worse is that the application is crashing, and in some cases it is crashing Windows or affecting other applications. So what happened? You tested your application. You fixed all the bugs you found. You fixed all the bugs the testers found. You thought you had all the errors handled. As any developer can tell you—and you probably know as well—there is no way to solve (or even find) every defect before you release an application. The best you can do is to handle the errors in a graceful manner. Does that mean including error handling in every single routine? Although some people might crucify me for this, the answer is not necessarily. In fact, you generally should not have any error handlers in business objects (I explain why later in the chapter). This chapter presents you with a lot of reusable code that can handle errors elegantly—no matter what the error is.

There is a wrong way and a right way to fail out of an application, and this chapter shows you how to fail the right way—with style. When you are done, your application will be able to report an error directly to technical support. You will know that a user encountered an error at the same time the user encounters it. You will be able to track error occurrence metrics and get detailed information about errors that occurred—in many cases, getting the exact line that caused the error.

Understanding Visual Basic 6 Error Handling Structures

Visual Basic (VB) 6 used the On Error Goto construct—or, for those developers who like to play with fate, the On Error Resume Next construct. Although ASP developers were forced to use the On Error Resume Next statement, it is a generally accepted axiom that there is no good reason to use anything other than the On Error Goto structure when writing a VB 6 application. For reference, the On Error Goto structure looks like the following:

 Private Sub Example()      On Error Goto errHandler      Some code here      Exit Sub errHandler:      Msgbox err.Number & " " & err.description End Sub 

There is one big problem with this code (well, there are several problems with this code), which can turn this into spaghetti code in a second: There is no easy way to include cleanup code. For example, if you opened a connection to the database at the top of the routine and an error occurred in the middle of the routine before closing the connection, the application would never get to the code that closes the connection. The way developers handled this was with the following code:

 Private Sub Example()      On Error Goto errHandler      Some code here Cleanup:      Some cleanup code here Exit Sub errHandler:      Msgbox err.Number & " "&err.Description      Goto Cleanup End Sub 

This is not a very elegant solution, and using Goto statements is the beginning of spaghetti code, so it will only get worse. You cannot really nest error handlers in a VB 6 routine. You can include multiple error handlers, but that becomes messy. .NET solves these problems and gives you an elegant way of handling errors. For VB developers, it brings you in line with other development languages.