Library tutorials & articles

Handling Errors in VB/VBA/VBS/ASP

The Resume keyword

In this segment I will elaborate a bit on the RESUME keyword in Visual Basic, however not go beyond the scope of this article.

As you have seen in the samples used in here, I have avoided using the On Error Resume. There is a personal preference in this selection form my side. I have a little bit to little trust in the ability of VB in exiting a recurring loop, especially as the one described in the GetAllErrors function. This function very well risk turning into one if the On Error Resume is used incorrectly.

I see it as good coding praxis to use the same detail in short samples as I would chose for longer source codes. Thus avoiding falling into sloppy coding habits and ending up with a permanent undetected bug. Consider the following about the Resume keyword, for future detailing of your own code.

You can chose between the following Resume statements.

Resume
Resume Next
Resume [n] 'where [n] is either a line number or a line name


Resume

By using RESUME without any further specifications, the execution will resume at the same line as initially raised the error event. If you called the function, producing the error from another function, your code will resume execution at the statement last calling the error raising function, in the procedure containing the error handling code.

Simply described, if your error handler is located in Function A and Function B is called causing an error, your resume will occur at the point where Function B is called in Function A.

If, on the other hand, your error handler is located in Function B, the resume will take place at the point in the Function B that caused the error, regardless of the statement made in A calling B.

(A bit legalese but I guess I'm getting good at it. *smiles)

Resume Next

By using RESUME NEXT, the execution will resume at the statement line immediately following the statement initially raising the error event. If you called the function, producing the error from another function, your code will resume execution at the statement immediately following the error raising function, in the procedure containing the error handling code. (or ON ERROR RESUME NEXT)

Simply described, if your error handler is located in Function A and Function B is called causing an error, your resume will occur at the point AFTER the statement where Function B is called in Function A.

If, on the other hand, your error handler is located in Function B, the resume will take place at the point AFTER the statement in the Function B which caused the error, regardless of the statement made in A calling B.

Resume [n] where [n] is either a line number or a line label

The RESUME [n] is somewhat different in its behavior. The n can be either a line number or line label. Far easier to use in VB is line labels, since VB doesn’t display line numbers, and we all know how tedious it is to count lines manually.

Assuming you have a line label in your source code named GoToMeOnRes:, you would call the Resume Line by simply saying;

RESUME GoToMeOnRes

However, you have to make sure that the line label (or number) is locate din the same procedure as the error handling code calling to it. It will NOT span over modules or even subs and functions.

Very important to hold in memory is, that you can NEVER use RESUME anywhere but in error-handling routines. If you attempt to do so, an error will instead occur.

The Caution about Resumes

Now let's return to the previous comment I made regarding good coding policies. As far I see it ( in my own opinion) the only place one should ever have use for a statement as…

On Error Resume

…would be in a loop. Now consider the event that an error actually does occur and you need to have a block for this error. If you are running a function or sub under On Error Resume, you would be stuck in an infinite loop. Thus never ending it and hogging up your system resources.

There is one more sample I have seen that actually made a fairly good use of the On Error Resume in a non-recursive way, however those samples are so few, and best solved with more safe versions of a few additional lines of code instead.

I will not even repeat the line sample here, because I don’t believe in teaching by showing what should NOT be done, but rather the opposite.

Comments

  1. 26 Apr 2005 at 11:36

    Is there any way to handle errors in INFINITE LOOP.


    for example,


    While Not blnIdeaFound
                   blnIdeaFound = ProcessDetector(EXE_NAME, False)
    Wend


    IF THE CONTROL IS INSIDE THE LOOP ( INFINITE LOOP ), IS IT POSSIBLE TO HANDLE THIS CASE WITH A ERROR HANDLER ?

  2. 01 Jan 1999 at 00:00

    This thread is for discussions of Handling Errors in VB/VBA/VBS/ASP.

Leave a comment

Sign in or Join us (it's free).

Mike J

Related discussion

Related podcasts

  • Christian Beauclair

    14 mai 2008 (�mission #0074) ::.Christian Beauclair: Stratégies de migration VB6 vers .NET Nous discutons avec Christian Beauclair des stratégies de migration VB6 vers .NET. Entre autres, nous discutons comment utiliser le "VB 6 Code Advisor" et le "Interop Forms Toolkit" pour ajouter la puiss...

Want to stay in touch with what's going on? Follow us on twitter!