|
David Wallwork
Senior Architect |
|
he traditional BBx® language has only three variable types; string (A$), number (A) and integer (A%). Since the introduction of embedded Java, BBj® gave the
BBx developer the ability to work with Java objects as well as these three native BBx types. In the 6.0 release of BBj, the
available variable types are even broader with the introduction of custom objects; objects defined completely in BBj program
files.
While using Java objects and BBj custom objects allows BBj developers to write sophisticated object-oriented applications,
these same object-oriented applications have the potential for hard-to-find type check errors. BBj 6.0 provides an easy-to-use
tool for discovering these errors – new type checking options in the bbjcpl executable that
compiles ASCII program files into binary tokenized programs. In this article, we will examine a small program that
demonstrates some of the errors that may occur when using object-oriented code, and then show how to discover these errors
using bbjcpl with these new options.
Consider the program in Figure 1. This program contains problems that will generate runtime errors when
executed.
|
|
Figure 1. Code sample that produces runtime errors |
Problem 1
At lines 200-220, this program assigns a string value to A! and a numeric value to B!, and then attempts to add A! to B!. Line 220 will
generate a runtime error because BBj does not support adding a numeric value to a string value.
Problem 2
The same problem occurs again at lines 300-320. The problem appears twice for demonstration purposes. Below we will resolve
the problem at line 200-220 differently from the resolution offered to the problem at line 300-320.
Problem 3
At line 420 the program attempts to pass a numeric value to the method getExistingNamespace(). Because that method accepts a string parameter rather than a numeric
parameter, the program will generate a runtime error when line 420 is executed.
The entire program is syntactically correct. This means it will load and list correctly and none of the lines will be marked
as syntax errors. And yet, we can see from looking at the program that these statements will cause runtime errors. One might
ask, “Why is the compiler not able to recognize these problems and mark them as errors during compilation?”
The reason that a human reading the program can recognize the errors is that the reader has additional information about the
variables. This additional information is type information. For example, the user understands from looking at line
200-210 that variable A! is of type "string" and the variable B! is of
type “number.” And the user can recognize that at line 220 the program is attempting to add a number to a string. Similarly,
at line 420 the reader knows (or can discover) that the method getExistingNamespace() requires a
string but that what is being passed is a number.
If there were a way to provide type information to the compiler, then the compiler would also be able to recognize these
problems. In BBj 6.0, declare statements provide this type information. The program in
Figure 2 uses declare statements to provide this information to the compiler.
|
|
Figure 2. Declare statement code sample |
By adding the declare statements at line 100, 110, and 400, we are telling the compiler what type we
want variables A!, B! and X! to represent in the
program. This allows the compiler to recognize some of the problems that are in our program. Because we have not declared the
type for the variables C! and D!, the compiler still cannot recognize the
problem at line 300-320. If we run the compiler on this program using the -t option that enables
type checking, we receive the output shown in Figure 3.
|
|
Figure 3. Type checking output using the -t option |
This output tells us that at line 200 we have mistakenly assigned a numeric value to a variable that is meant to be a string
variable and that at line 420, we have attempted to invoke a method that does not exist.
Also notice this output still does not give any information about our problem at line 300-320 because the compiler has no type
information about the variables C! and D!. If we run the compiler with the
-t -W options that enable type checking and related warning messages, it will list all the lines
that have type check errors. In addition, it will also list all the lines that may have errors but could not be checked
because there is no type information for their variables. Using the -t -W options, we receive the
output displayed in Figure 4.
|
|
Figure 4. Type checking output using the -t -W options |
This output tells us about the errors on line 200 and line 420, and warns us that lines 300-320 use variables that have not
been declared and so could not be checked for errors.
Summary
Using the declare verb along with the type
check options of BBj 6.0 allows the developer to discover many programming problems at compile time which, if left
undiscovered, would become runtime errors. Compile time errors are vastly preferred since they appear during development and
provide an opportunity for correction before deploying the application. Runtime errors, on the other hand, occur during
execution of the program – oftentimes in a production environment – and therefore, tend to be more costly and
difficult to track down.
|
