Home

Error Handling

 

Introduction to Errors

 

Overview 

Probably no matter how careful and meticulous you are, some time to time, there will be problems with your code or your application. Some problems will come from you. Some problems will be caused by users. And some problems will be caused by neither you nor your users. This means that there are things you can fix. Those you can avoid as much as possible. And there are situations beyond your control. Still, as much as you can, try anticipating any type of problem you imagine may occur when a user is using your application, and take action as much as possible to avoid bad situations.

Error Categories

As mentioned above, there are three main types of problems that you will deal with, directly or indirectly:

  1. Syntax: A syntax error comes from your mistyping a word or forming a bad expression in your code. It could be that you misspelled a keyword such as ByVel instead of ByVal. It could also be a bad expression such as 524+ + 62.55. It could be a "grammar" error such as providing the name of a variable before its data type when declaring a variable (quite common for those who regularly transition from different languages (C/C++, Pascal, C#, Java))

    When you use Microsoft Visual Basic to write your code, it would point out the errors while you are writing your code, giving up time to fix them. When your database runs, it can let you know about other syntax errors. For this reason, syntax errors are almost the easiest to fix because, most of the time, the problem would be pointed out and you can fix it. 
  2. Run-Time: After all syntax errors have been fixed, the program may be ready for the user. There are different types of problems that a user may face when interacting with your program. For example, imagine that, in your code, you indicate that a picture would be loaded and displayed to the user but you forget to ship the picture or the directory of the picture indicated in your code becomes different when a user opens your application. In this case, when you tested your database in your machine, everything was fine. This is a type of run-time error.
    Run-time errors are mostly easy to fix because you will know what problem is occurring and why.
  3. Logic: These are errors that don't fit in any of the above categories. They could be caused by the user misusing your application, a problem with the computer on which the application is running while the same application is working fine in another computer. Because logic errors can be vague, they can also be difficult to fix.

One of the best qualities of an effective programmer is to anticipate as many problems as possible and to deal with them in the early stages. Some problems can be easy to fix. With some others, you will simply need to build more experience to know how to fix them. Unfortunately, it will not be unusual to have users asking you to fix your application when a problem may not come from it.

 

Error Handling

 

Introduction 

From its early stages, Microsoft Visual Basic has always made it a priority to deal with errors. Most or early errors occur in your code. The Microsoft Visual Basic Code Editor can help you detect syntax errors and fix them. For example, when a certain error occurs while you are writing your code, a message box would display, prompting you to fix the problem. If there is a syntax error that that the IDE didn't signal or that you ignored when writing your code, you would find it out when the form or report is previewed.

A run-time error is one that occurs when using your application. Consider the following form:

Private Sub cmdCalculate_Click()
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
End Sub

Here is an example of executing it:

The first aspect your should take into consider is to imagine what could cause a problem. If you think there is such a possibility, you can create a label that could be used to transfer code if a problem occurs. Here is an example:

Private Sub cmdCalculate_Click()
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
ThereWasAProblem:
        MsgBox ("There was a problem when executing your instructions")
End Sub

If you create such a label, you should specify when to jump to that label. Otherwise, as in this case, the label section would always execute. Here is an example of running the above version:

In this case, we want the label section to execute only when we want it to. To prevent the execution from reaching this section if not directed so, you can add an Exit Sub line above the label section:

Private Sub cmdCalculate_Click()
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
ThereWasAProblem:
        MsgBox ("There was a problem when executing your instructions")
End Sub

This time if you execute the program with an appropriate value, the label section would not be reached.

 

In Case Of Error, Jump To Label

The above code will work fine. When you preview the form, imagine that the user types an inappropriate value such as 24$.58 instead of 244.58. In this case, the value is not a number, the program would "crash" and let you know that there was a problem:

With some experience, you would know what the problem was, otherwise, you would face a vague explanation. If a problem occurs when a person is using your database, the computer may display an insignificant message to the user who would not know what to do with it. Therefore, you can start by creating an appropriate label as introduced above. An error normally occurs in a procedure. Therefore, to make your code easier to read, you should create a label that shows that it is made for an error instead of being a regular label. The label should also reflect the name of the procedure. Here is an example:

Private Sub cmdCalculate_Click()
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
cmdCalculate_Click_Error:
        MsgBox ("There was a problem when executing your instructions")
End Sub

When you think there will be a problem in your code, somewhere in the lines under the name of the procedure but before the line that could cause the problem, type On Error GoTo followed by the name of the label that would deal with the error. Here is an example:

Private Sub cmdCalculate_Click()
    On Error GoTo cmdCalculate_Click_Error
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
cmdCalculate_Click_Error:
        MsgBox ("There was a problem when executing your instructions")
End Sub

This informs the compiler that, if there is a problem when this code executes, jump to the indicated label. When the On Error GoTo statement is used, this indicates that if any type of error occurs while the code of this procedure is executed, transfer the compilation to the label. In this case, as soon as something bad happens, the compiler marks the area where the problem occurred, skips the normal code and jumps to the label indicated by the On Error GoTo line. After the section of that label is executed, the compiler returns where the error occurred. If there is nothing to solve the problem, the compiler continues down but without executing the lines of code involved. In this case, it would encounter the Exit Sub line and get out of the procedure.

 

In Case Of Error, Jump To Line #

Although the label is more explicit, it only indicates to the compiler what line to jump to in case of a problem. The alternative is to specify a line number instead of a label.

Resume 

If a problem occurs in your code and you provide a label to display a friendly message as done above, the compiler would display the message and exit from the procedure. If this happens, as mentioned above, when the compiler returns where the problem occurred, you can provide an alternative. For example, in our program, if the user provides an inappropriate value that causes the error, you can provide an alternate value and ask the compiler to continue as if nothing happened. In this case, you want to compiler to "resume" its activity.

To indicate that the program should continue, you can use the Resume keyword. Here is an example:

Private Sub cmdCalculate_Click()
    On Error GoTo cmdCalculate_Click_Error
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    
    Resume
    
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
cmdCalculate_Click_Error:
        MsgBox ("There was a problem when executing your instructions")
End Sub

When an error occurs, if you want the program to continue with an alternate value than the one that caused the problem, in the label section, type Resume Next. Here is an example:

Private Sub cmdCalculate_Click()
    On Error GoTo cmdCalculate_Click_Error
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
cmdCalculate_Click_Error:
        MsgBox ("There was a problem when executing your instructions")
        Resume Next
End Sub

In this case, since any numeric variable is initialized with 0, when the compiler returns to the line of code that caused the problem, it would use 0 as a substitute to the inappropriate value. Based on this, you can provide a new value to use in case of error. Here is an example:

Private Sub cmdCalculate_Click()
    On Error GoTo cmdCalculate_Click_Error
    Dim Number#
    Dim Twice#
    
    Number = [txtNumber]
    Twice = Number * 2
    [txtResult] = Twice
    
    Exit Sub
    
cmdCalculate_Click_Error:
        MsgBox ("There was a problem when executing your instructions")
        Number = 16
        Resume Next
End Sub

Here is one example of running the program:

 

 

 

 

Previous Copyright © 2005-2010 FunctionX, Inc. Next