How to refactor VB6 code to prevent runtime errors

Question

VB6 application experiences runtime errors in different places.

I know this is the result of poor error handling, but is it possible to analyze the code to see where it is prone to errors at runtime?

Answer 1

You need to make sure that each of the methods (functions, substitutions, properties ...) in your code base contains error handling instructions. It is probably true that not everyone can generate a runtime error, but it will protect the application from crashes without much preliminary analysis.

Make sure that before any executable line of code containing the inscription "On Error GoTo ...", the inscription, and then make sure that it is marked with the error handling code at the bottom of the method. I used a free tool called MZ-Tools 3.0 , which allows you to automate the inclusion of this text. The parameters have a tab "Error Handler", which allows you to specify which text you want to place and where. It looks like this:

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 to a log file that I can view.

Answer 2

Any application is prone to runtime errors when there is no call processing for external calls, so you can identify these points as the beginning.

I used a free tool (many years ago) that could embed error handling in VB6 code, which would at least lead to log errors and the point at which they occurred.

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

Answer 3

Common sources of runtime errors in VB6 applications include

• Access to a key in a collection that does not exist
• Call a method or property for an object that is not
• Using CLng to convert a string to a number when the string is null
• Access to the array beyond its length (for example, after calling Split, and then, provided that the string contains the number of expected fragments)

Thus, in addition to others suggesting and analyzing where the actual errors come from, you can start by looking for such areas in your code and placing the corresponding errors when processing them. Keep in mind that often the best “error handling” does not include the use of “About Error” at all, but prevents the error in advance by checking this boundary case, for example

• If no object is nothing
• If Len (string)> 0
• If UBound (array)> x

etc...

Answer 4

Here are some good answers with On Error GoTo recommendations and common errors that fall into the cracks mentioned by bwarner .

But it’s possible to expand the scope and use built-in tools for analyzing code, such as breakpoints, expression for observation, and especially good for debugging errors at runtime, the local computer window (often missed when debugging, but very powerful) and call stack, Here you can get more information: Debugging code and error handling

Other things to think about may be helpful:

• Invest in a tool that helps you with the analysis, such as CodeSMART 2009 for VB6 or the VB Analyzer Project .
• Try connecting your existing application to VB.NET - not really a port, but to view the conversion log for things that need fixing.

Answer 5

After Ryan’s response and comment, you don’t need to put error handling in each procedure, only every event and Sub Main() (and API callbacks if they do not already have it).

API callbacks refer to routines called directly by Win32API, most often passed to Declared using AddressOf . (1.e find your code for AddressOf and make sure all the routines mentioned as arguments have error handlers that catch errors and prevent them from trying to bubble up.)

And I just noticed that this really doesn’t answer the question asked (although given the comment in response to Ryan’s answer, this is a good first step): after you handle the errors in each event, etc., you will catch all errors, but you cannot directly analyze where all errors occur. You will need to extend the error log to at least all routines called by events that log errors in order to more accurately determine the exact source of each error.

Answer 6

In VB6, a runtime error occurs exactly when the Event function is called without error handling. Therefore, at least all your event handling functions (for example, Form.Open ()) should be surrounded by an error handler (yes, I know that VB6 does not have them), which can be implemented like this (we do this in all our applications for example:

Use this as the first line of the EVERY event handling function (this is a large valid label that sets On On at the end):

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

Now use this at the end of all these 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 lines with the module name and function name. And replace each On Error Goto 0 with On Error Goto ErrorHandler .

Now create a handleError function with the given arguments (in my application, it automatically sends an error report to our bugtracking system) and displays a nice error message.

We even pushed it a bit further by pre-creating a process that adds similar lines to all the others (meaning functions not related to the event, or functions just called by other functions) to remember the line in which the error occurred and accumulate the full trace stack (yes, stacktraces in VB6!). In addition, this process adds line numbers to each line, so they are listed in the Erl part of the error handler.

Our tool is written as some MS Access modules, so I can’t just provide it to you, but you see where you should look for it.