Dealing with runtime errors

In any environment, runtime errors are bound to occur. These types of erros occur because something in the environment is not the same as when the programmer wrote the application. Two big examples are when a program does not take into accoutn the fact that someone may have a record that the program want, and it's locked, and the other is when a network or server error occurs and files that you expect to be open and accessible are not.

In order to deal with runtime errors you have to code for the possibility that what you want may not happen. For example, if you code a routine to update all of the values in a column in a table like this:

SELECT FIRST LOCK FILE "CUSTOMER"

WHILE NOT EOF("CUSTOMER")

Status.CUSTOMER = "Updated"

STORE FILE "CUSTOMER"

SELECT NEXT LOCK FILE "CUSTOMER"

WEND

You have to be prepared for the fact that it might be IMPOSSIBLE to select the "next" record (or even the first one) and successfully apply a LOCK to it. In this case, you must write your program to anticipate the fact that if an error occcurs, either we have to skip over the record, wait for it to become free again (which may never happen) or undo all previous records that were changed. A lot of this coding decision depends on what you want the operation to do under failure mode like this.

Another common runtime error in some Superbase applications involves not using explicit file references. Using the above example, we could write the same code 2 different ways (pay careful attention to the filename "CUSTOMER"

Example 1 (bad example)

FILE "CUSTOMER"

SELECT FIRST LOCK

WHILE NOT EOF("")

Status = "Updated"

STORE

SELECT NEXT LOCK

WEND

Example 2 (good example)

FILE "CUSTOMER"

SELECT FIRST LOCK FILE "CUSTOMER"

WHILE NOT EOF("CUSTOMER")

Status.CUSTOMER = "Updated"

STORE FILE "CUSTOMER"

SELECT NEXT LOCK FILE "CUSTOMER"

WEND

In the first example, we first attempt to switch the "current" file to be the CUSTOMER file. Then we loop from the first record, all of the way to the end, updating the status field in the CUSTOMER file. What happens if (in the first example) the program has run out of Windows's file handles and cannot switch open the CUSTOMER file. In this case, whatever file happends to be the "current" file will have all of it's data update! Yikes! This isn't what we want and in some cases can change values in the wrong file! In example 2, we are explicitly naming the CUSTOMER file in each operation, to insure that under no circumstances will we operate on any other file other then the CUSTOMER file.