How to refactor VB6 code to prevent run-time errors

Question

A VB6 app is experiencing a run-time errors at a variety of places.

I know this is the result of poor error handling, but is it possible to analyse the code to see where it is susceptible to run-time errors?

Answer 1

Any application is susceptible to run-time errors where there is no error handling around calls to external resources, so you could identify those points as a start.

I've used a free-tool (many years ago) that could retro-fit error handling to VB6 code, which would at least log errors and the point that they occurred.

Here it is: The HuntErr Addin for easy error handling in VB6

Answer 2

Add a line on error resume next in the first line of every function/procedure, this will skip the error line, so the program won't be closed by any possible error.

Answer 3

Common sources of run-time errors in VB6 apps include

• Accessing a key in a collection that doesn't exist
• Calling a method or property on an object that is nothing
• Using CLng to convert a string to a number when the string is null
• Accessing an array beyond its length (like after calling Split and then assuming that the string has the number of pieces you expected)

So besides doing what others have suggested and analyzing where the actual errors are coming from, you could start by looking for areas such as these in your code and putting appropriate error handling around them. Keep in mind that often the best "error handling" doesn't involve using On Error at all, but preventing the error ahead of time by checking for these boundary case, like

• If Not Object Is Nothing
• If Len(string) > 0
• If UBound(array) > x

etc...

Answer 4

You need to make sure that every one of the methods (functions, subs, properties...) in your code base has an error handling statement. It's probably true that not every single one can generate a run time error, but that will protect the application from crashing without a lot of upfront analysis.

Make sure there's a statement before any executable line of code that says "On Error GoTo..." with a label, and then make sure to put that label with some error handling code at the bottom of the method. I've used a free tool called MZ-Tools 3.0 that allows you to automate the inclusion of this text. There is an Error Handler tab in the options that lets use specify what text you want to put in and where. This is what mine looks like:

    On Error GoTo l{PROCEDURE_NAME}_Error

    {PROCEDURE_BODY}

    Exit {PROCEDURE_TYPE}

l{PROCEDURE_NAME}_Error:

    LogError "{MODULE_NAME}", "{PROCEDURE_NAME}", Err, Err.Description

Then I just make sure that the LogError function exists and writes the error out to a log file that I can review.

Answer 5

Following Ryan's answer and the comment in response, you don't have to put error handling in every routine, just every Event and Sub Main() (and API callbacks if they don't already have it).

API callbacks refer to routines called directly by the Win32API, most often passed to Declared functions using AddressOf. (I.e. search your code for AddressOf and ensure all routines mentioned as arguments have error handlers that catch errors and do not allow them to attempt to bubble up.)

And I've just noticed this doesn't really answer the original question asked (although given the comment in response to Ryan's answer it is a good first step): Once you have error handling in every Event, etc, you will catch all errors, but you won't be able to directly analyse where all errors occur. You will need to extend the error logging to at least all the routines called by the events that log errors to more accurately locate the exact source of each error.

Answer 6

In VB6 a Runtime error occures exactly when an Event function is called without error handling. So at least all your event handling functions (like Form.Open()) should be surrounded by an error handler (yes, I know VB6 does not have them), which can nicely be implemented like this (We do it in all our applications like this):

Use this as the first line of EVERY event handling funtion (it is a large valid label which sets the On Error at the end):

¦¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯: On Error GoTo ErrorHandler:

Now use this on the end of all those functions:

¦____________________________________________________________________________________________________________________________________: Exit Sub
ErrorHandler: handleError CodeDb, "Form_frm_filter_deletecolum", "cmd_deletecolum_Click", err.Number, err.description, err.Source, err.LastDllError, err.Helpfile, err.HelpContext, Erl: err.Clear

But replace the two strings with the module name and function name. AND replace each On Error Goto 0 with On Error Goto ErrorHandler.

Now create a function handleError with the given arguments (in my app it automatically sends a bug report into our bugtracking system), and display a nice error message.

We even pushed this a bit further, by having a prebuilt process that adds similar lines to all other (means non-event functions, or functions just called by other functions), to remember the line in which the error occured and to accumulate a complete stack trace (Yeah, stacktraces in VB6!). In addition this process adds line numbers to each line so they are given in the Erl part of the error handler.

Our tool is written as some MS Access modules, so I can't simply provide it for you, but you see where you have to go for it.

Answer 7

can you make a code for an open and save button with a error handler because im just new at vb6