HP 3000 Manuals HP 3000 Manuals
Types of Error
There are two types of run-time error; exceptions and I/O errors. I/O
errors are either fatal or recoverable; the latter being reported by the
operating system so that you can trap them and take steps to recover from
them if at all possible. Exceptions are fatal errors which are not
reported and so cannot be trapped.
Exceptions
These are fatal errors covering conditions such as arithmetic overflow,
too many levels of PERFORM nesting, and subscript out of range.
I/O Errors
These are either fatal or recoverable errors, which cause one of the
following to take place:
* If you did not specify a FILE STATUS clause for the file on which
the error occurred then the error is treated as fatal. That is,
the program terminates immediately with the RTS displaying its own
message on the console in the format given above. See the chapter
File Status Codes for details of how to define the file status.
* If you specified a FILE STATUS clause for the relevant file then
the value "9" (which indicates that an operating system error
message has been received) is placed into status-key-1 and the
operating system or RTS error number is placed into status key 2.
You must examine status key 1 after each file operation to ensure
that the operation has been carried out successfully. 0 in status
key 1 indicates the successful completion of a file operation; any
other value indicates an error condition of some type.
If an error condition is reported, the action which your program
then takes is entirely your responsibility. If your program does
not terminate when an error is reported, its subsequent behavior
might not be as you would expect.
Fatal Errors.
Fatal errors cause a message to be output to the console, and once this
error message has been displayed your program terminates immediately.
Although you cannot recover from such an error during the run of your
program, once it has terminated you might be able to take steps to
rectify the conditions which caused the error to occur. The list of
run-time system error messages gives hints on how this might be achieved
for individual errors.
Recoverable Errors.
You can trap recoverable errors in your program, but the action you take
when one of these errors is received is your responsibility.
Error Handling
Having received a file error you can deal with it in one of many ways.
You might want your program to display its own general error message,
close any open files (if this is possible) and terminate. This should
enable you to save any data which you have already written to the files.
This data could be lost if you do not trap the error.
Should you want to recover from an error and to continue to run your
program, code your program in such a way as to take action should a
particular error be reported. For example, if you receive a "file not
found" error then your program could prompt you to insert a disk
containing the required file into a specified drive, if your operating
system supports this.
Hints on how to recover from specific errors are given later in this
chapter but you will be able to follow these hints only if you have coded
your program in such a way as to be able to take advantage of them.
The following points suggest ways in which you might want to code your
program to handle recoverable errors.
* Use AT END (which checks for a value of 1 in status key 1), or
INVALID KEY (which checks for a value of 2 in status key 1)
clauses where appropriate. You do not need to declare FILE STATUS
items in this case.
* Use Declaratives which check that status key 1 is not equal to 0
(that is the operation was not completed successfully) for all
file-operations that have no AT END or INVALID KEY clauses. You
should declare FILE STATUS items in this case.
* Declare FILE STATUS items and check for a value in status key 1 of
either 9 which indicates an RTS error, or nonzero which shows that
the file operation has not been successfully completed. You
should explicitly check the status byte after each file operation.
* Do not use the FILE STATUS clause or AT END or INVALID KEY, in
which case the RTS terminates immediately should any file error be
received. In this situation all error messages are treated as
though they were fatal with the relevant RTS error message being
output to the console.