What is a RTE (Runtime error) ?

There are four ways that a Clipper program can terminate fatally. Each of these types of terminations represent different causes for the termination and need to be considered separately.

Runtime recoverable errors :

Runtime recoverable errors are expected to happen. These errors generally occur either because of mistakes in your code (e.g. type mismatch, divide by zero) or because of some condition of the environment (e.g. out of file handles, file sharing violations, memory low). These errors can be trapped in the error system and therefore do not necessarily terminate the application.

If the default error system is being used in the application then runtime errors are reported in the following format:

Error | Warning <subSystem>/<subCode> <message text>
              <filename> | <operation>

Overview on error recovery :

Error recovery failure

Clipper’s error system depends on communication taking place between the error handler and the subsystem that generates the error. The error handler communicates with the subsystem by returning a value indicating what the subsystem should attempt to do to recover from the error. The legal values that can be returned are determined by the values contained in the error object passed to the error handler for Error:canRetry, Error:canDefault, and Error:canSubstitute. If the error handler returns an invalid value to the subsystem (or returns to the subsystem at all when these values are all false), then an error recovery failure is reported and the application is terminated.

This exit condition always has the same format:

Error recovery failure, <operation> (<line number>)

User abort :

The user can abort your application by pressing Alt-C or Ctrl-Break at anytime during the execution of your application unless you have specifically disabled this feature. You can disable it with SETCANCEL (.F.) or SET(_SET_CANCEL, .F.).

This exit condition always has the same format:

Cancelled at: <operation> (<line number>)

Missing error handler :

If code is executed before any ERRORBLOCK() can be installed, an unrecoverable error will be generated that indicates that no error handler is present. This usually occurs if there is code in ErrorSys() before the ERRORBLOCK() function is called. All code should be moved after this line if possible.

No ERRORBLOCK() for error at: <operation>
    (<line number>)

Runtime recoverable error categories :

This section is a summary of runtime recoverable error messages that are possible when executing a Clipper application using the supplied subsystems. The messages are divided into categories according to subsystem. Each category is described below, followed by a listing of all messages in each category.

BASE Errors :

BASE error messages indicate errors generated by the Base system.

The general format of a BASE error message is as follows:

Error | Warning BASE/xxxx <message text> <filename> |
     <operation>

TERM Errors :

TERM error messages indicate errors generated by the Terminal subsystem. The general format of a TERM error message is as follows:

Error | Warning TERM/xxxx <message text> <filename> |
     <operation>

DBFNTX Errors :

DBFNTX error messages indicate that an error occurred during a database or index operation utilizing the DBFNTX database driver. The general format of a DBFNTX error message is as follows:

Error | Warning DBFNTX/xxxx <message text>
 <filename> | <operation>

DBFNDX Errors :

DBFNDX error messages indicate that an error occurred during a database or index operation utilizing the DBFNDX database driver. The general format of a DBFNDX error message is as follows:

Error | Warning DBFNDX/xxxx <message text>
      <filename> | <operation>

DBCMD Errors :

DBCMD error messages occur in the database command set and are unrelated to a particular driver. They occur as a result of command usage rather than from a failure of the driver itself.

Error | Warning DBCMD/xxxx <message text>
       <filename> | <operation>

Runtime unrecoverable errors :

Unrecoverable errors are runtime errors that for some reason cannot make use of the error system. Like runtime errors, it is normal for these errors to occur. This is usually because the system is unable to execute the error block. Almost all of these errors are therefore related to the environment (e.g. out of memory, errors reading code to execute from disk) and can be fixed by making a change to the environment.

Unrecoverable errors always have the same format:

<operation> (<line number>) Unrecoverable error xxxx:
     <message text>