Pinpointing Exactly Where A Crash Occurs

Provided by: Luke Chung, President of FMS, Inc.

Whether you're writing Microsoft Access or Visual Basic applications, a comprehensive error handling architecture is critical to a professional solution. Error handling in your VB/VBA code lets you trap unexpected errors and gracefully exit your application without causing an end user to suffer an unhandled crash on their own.

Ideally, your error handler documents what went wrong so that you can diagnose the problem and quickly fix it.

Since we've created applications in use by customers around the world, and cannot physically visit them to deal with issues, we've created a very robust error handling architecture to best address unexpected behavior with the goal of taking care of customers and constantly improving our products.

One of the most important parts of this is documenting the line where a crash occurs. By knowing the error message and offending line, one can often determine the problem without asking the user for more information. Information the user may no longer remember or recall accurately.

Simple things like, "Oh, that's where I need to trap for Null", or "That's where division by zero happened" are addressed by knowing this basic information.

It also makes it clear that the developer is at fault -- not the user -- which can be half the battle (and I speak from experience as a developer who has never but still thinks he can write bug free code).

Error Object

The Error Object (Err) provides vital information when a crash occurs.

• Err.Description gives the error description

• Err.Number the error number (useful if users are in another language).

With the Error object, you can usually understand what the error is. That's a start. Unfortunately, it does not reveal the module or procedure name, which needs to be handled manually but is beyond the scope of this tip.

ERL Function

Less well-known is the ERL function which gives you the line number where an error occurs. Most developers don't use this because this function returns 0 if the crashing line isn't numbered.

The trick is to number all your lines before you deploy your application to your users. If you do that, the ERL function identifies exactly where a crash occurs:

Sub SampleErrorWithLineNumbers()

     Dim dblNum As Double
     Dim dblRnd As Double

10   On Error GoTo PROC_ERR

     ' Randomly crashes on a line below:
20   dblRnd = Rnd()
30   Select Case dblRnd
       Case Is < 0.2
40       dblNum = 5 / 0
50     Case Is < 0.4
60       dblNum = 5 / 0
70     Case Is < 0.6
80       dblNum = 5 / 0
90     Case Is < 0.8
100      dblNum = 5 / 0
110    Case Else
120      dblNum = 5 / 0
     End Select
130  Exit Sub

PROC_ERR:
140 MsgBox "Value: " & dblRnd & vbCrLf & _
           "Error Line: " & Erl & vbCrLf & _
           "Error: (" & Err.Number & ") " & _
           Err.Description, vbCritical
End Sub
 

In the silly example above all the dblNum equations crash because of division by zero. The Rnd function gives a random number between 0 and 1, and based on the value dies on one of the lines in the Select Case statement. The ERL function identifies which line and displays a message box:

In this case, the value was 0.57, and we see it dies in the section < 0.6.

Obviously, this is just an example of how ERL works. In a real application, we'd have a global error handler invoked in the PROC_ERR section, where the error information would be written to a file along with any other information about the environment.

As for adding line numbers to code, we do that after we've finished writing our application as one step in our delivery process (we don't write code with line numbers). Other delivery steps include emptying temporary tables, resetting default values, setting the version number, etc.

We use our Total Visual CodeTools product to apply the line numbering. It's part of its Code Delivery feature and is one of the most important steps we take to build quality into our applications. Its New Procedure Builder is also very helpful for writing new procedures with the error handling and commenting structure we like. Finally, its Code Cleanup feature lets us apply our error handling to all procedures that lack error trapping which is great for taking over an existing application. 

The use of line numbers and ERL have been critical to resolving many obscure issues and improving our products over time.

For more information on better code writing and debugging, read my paper on Access, VBA, and Visual Basic Debugging Tips and Techniques

Good luck!