Handling errors

Errors are something we have to face in the real world so everything you write must have something to handle errors. Different languages have different mechanisms for handling errors but the same concepts will apply to them all.

Basic concepts

Coverage

It's very tempting to take a short cut and leave the error handling out of a short piece of code. Resist this temptation and make sure that you've made provision for errors no matter where they may crop up.

Recursion

The error handler cannot handle errors inside itself. The first action of an error handler routine should always be to redirect the error handling. If this is overlooked then any error in the error handler code will call the error handler and run into the same error again, and again, and again until something in the internal structure of your program overflows.

This may mean that an error in the error handler leads to a messy crash but at least it will crash immediately and you will get an accurate report of the cause.

Robustness

The error handler has got to work so it should be as simple as possible. It should be completely self-contained. If it uses your bespoke user interface object to display a message for the user then it will lock up if the error happens to be in that very object.

Levels of response

Not all errors are equally serious. Your error handler should have at least four levels of response:

Silent

Use this for diagnostic records so that you will get advance warning of future problems. Use it as a trace mechanism to profile the typical usage of the system. If you are worried about the speed of a particular operation then create a log entry at the start and end of the process. This will tell you how long it really takes for a typical user to process real data on an everyday workstation

Try again

Most of the errors in this category relate to the interface with the hardware or with the user. The cause might be a printer that's empty of paper or a drive with no disk or CD in it. The error handler should tell the user what has happened and give them the opportunity of trying again or abandoning the operation.

Avoid

These too are typically caused by the failure of something outside the application but this time it's something over which the user has no control. An example might be a problem with a communications link which means that data cannot be imported from another site. The error handler should tell the user what has happened and confirm that the rest of the application is still running as normal.

Abandon

There are two sub-divisions here: problems with the installation such as the failure of a network drive and problems with the application such as a Divide By Zero error. In either situation, the error handler should shut the application down as safely as possible.

Messages to the user

The user rarely cares what has gone wrong and only needs two items of information:

What damage has been done.
How do I repair it.

The user should never see a raw error message from the programming language. Something like 'Invalid File Offset' will be utterly meaningless to most users. If the user has to report the error to an internal Help Desk then display a message with an error number - something like:

Error 42
Please phone the Help Desk on extension 1234.

Error log

An error log is invaluable if you are supporting an application from off site. The log should record time, date, user, and workstation so that you know who had the problem and it should record the name of the program file and the line number so that you know where the problem occurred. Rather than having to listen to exaggerated tales of problems you can read the log and see exactly what has been happening.

Consider having two types of error log; a simple log that merely records the facts listed above and a verbose log that records far more detail such as the amounts of free disk and memory space, the version and sub-version of the operating system, and chain of programs and operator actions that lead to the error. The verbose log will make the application run more slowly and will generate a large log file but sometimes that will be the only way of investigating a problem.

The error log can be recorded as a simple text file but if you store it in a table then you will be able to analyse it and extract information such as the most common types of error and the frequency of errors.

The Site Search feature requires JavaScript. If your browser does not support Javascript then please use our Site Map instead.

Hints & tips

The textbox class in Visual FoxPro 9 has a new Autocomplete property which shows the user the previous values that have been entered in that textbox.
Autocomplete in VFP 9

Your Access database will look more impressive if you add custom toolbars...
Custom toolbars

FoxPro has always had functions to read and write files at a low level...
Foxpro low level file functions

More...
More pages of hints and tips for users of Microsoft FoxPro and Access databases.

Site Map