|
As mentioned above, there are three main types of problems
that you will deal with, directly or indirectly:
- 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.
- 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.
- 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.
|
|
|
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. |
|
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:
|
|
|
