Check Your Code for Error Checking and Recovery

While you were developing your application, you linked with the Vermont Views development library. This library provides error checking automatically. There are two types of errors detected by the development library: development errors, which are errors that should be caught and fixed during the testing phase, and run-time errors, which are errors that can always occur during run-time. Examples of development errors include referencing a field that does not exist or setting a window on the screen after it is already set. Examples of run-time errors include being unable to open a file or unable to allocate memory.

The overhead associated with checking for errors in the development library is significant. To remove this overhead, you can link your programs with the production library. However, this disables all Vermont Views error checking. Your application is then solely responsible for checking for and recovering from run-time errors. Before linking with the production library, check your code carefully to ensure that you test the return value from every Vermont Views function that can return a run-time error. Be sure that your application contains the appropriate code to recover from run-time errors or terminate your application.

To determine which Vermont Views functions can return run-time errors, check the function reference pages in the Function Reference. The function reference pages list only run-time errors.

In general, run-time errors involve: an inability to open, read, or write to a disk file; an inability to allocate memory; and failure to find a keyword in a memory file.

Failure to check for and recover from run-time errors can cause serious problems in your application, including severe memory overwrite problems.

As an example, the following code does not check for run-time errors:

int usr_func(fmp)

FORMPTR fmp;

{

    DLIBPTR libp;

    DFORMPTR my_formp;

    MY_DATA data;



    libp = dl_open("my_lib.vvd");

    my_formp = dl_fmget("my_data", &data, NULLP, NULLP,

            libp);

    fm_proc(0, my_formp);

    fm_free(my_formp);

    dl_close(libp);

    return(1);

}

No error checking is done in this example. Both dl_open() and dl_fmget() can fail due to run-time errors. Since no error checking is done, the program would continue to run, using NULLP for the value of libp and/or my_formp. This could result in processing a non-existent form, and eventually attempting to free memory at location 0:0, where no memory was allocated. All these errors are memory overwrite errors which could have serious implications. These errors would be caught by the development library, but not by the production library. Properly structured code would check for run-time errors, and would appear as follows:

int usr_func(fmp)

FORMPTR fmp;

{

    DLIBPTR libp;

    DFORMPTR my_formp;

    MY_DATA data;



    if (libp = dl_open("my_lib.vvd"))

    {

        if (my_formp = dl_fmget("my_data", &data, NULLP,

            NULLP, libp))

        {

             fm_proc(0, my_formp);

             fm_free(my_formp);

        }

        dl_close(libp);

    }

    return(1);

}