Exception Handling
From CometWiki
Exception Handling
All input/output statements in Internet Basic allow for handling of runtime exceptions.
Here are some typical examples:
- The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)
- The program attempts to read a record from an existing file, but the record (and its key) does not exist. (Result: Comet exception 32 -- key not found.)
- The program attempts to read a record from an existing file, but the record is locked (extracted) by another user. (Result: Comet exception 33 -- Record Unavailable--Extract Error.)
- While reading a data record, the program attempts to read a numeric value, but the actual data field contains a non-numeric character. (Result: Comet exception 46 -- non-numeric input in a numeric field.)
- While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)
Each of the above situations results in a Comet runtime exception.
The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution.
For example:
READ (1,1000) KEY=CUSTNUM$, EXCP=9999
In this example, a statement-label of 9999 is specified as the exception path for the READ statement.
This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending.
There are two exception branching parameters:
EXCP=statement-label branches to statement-label
.
EXCPSUB=statement-label branches to subroutine
In any exception routine, the program may include statements to inquire into the nature of the exception. This is done with the Comet system variable named EXCP, which contains the number of the most recently encountered Comet exception.
See Comet exception messages for a complete list of runtime exceptions.
Following the example from above, an exception routine could look like this:
9999 IF EXCP=32 THEN PRINT (0) "KEY NOT FOUND" & GOTO 100
IF EXCP=33 THEN PRINT (0) "RECORD EXTRACTED" & GOTO 100
This routine, starting with the label 9999, checks the system variable EXCP for two of the most common values that might be encountered during a READ:
| EXCP value | Meaning |
| 32 | The specified key was not found in the key list |
| 33 | The specified key was extracted by another user |
In an exception routine, there are several ways to deal with runtime exceptions.
One way is to simply branch back to a logical starting place in the program and start over.
Another is to retry the action that caused the exception. This is done with the AGAIN statement.
Another course is to instruct the program to come to an abnormal end, in the case where all possible exceptions have been tested for and handled.
For example:
9999 IF EXCP=33 THEN PRINT (0) "RECORD EXTRACTED" & AGAIN
IF EXCP=32 THEN PRINT (0) "KEY NOT FOUND" & GOTO 100
ERROR
In this exception routine, if the exception is 33, the program will display a message that the record is extracted and try the I/O statement again (as specified by the AGAIN statement).
Note: This method should be used with care, as it could result in and endless loop of trying the I/O statement, testing for exception 33, trying the I/O statement, etc.
In the above routine, if exceptions 32 and 33 are not the cause, the program is instructed to take an abnormal end (the ERROR statement does this).
When ERROR is encountered, the QENDITOR program will be executed and the Comet exception will be displayed on the controlling terminal.
Other exception handling statements include ERRORTO and ERRORSUB, statements that set default exception paths.
Comet32 includes the NOEXCP option on file system statements so you may choose to ignore any non-fatal exception.
