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 may 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 will terminate immediately.
Although you will not be able to recover from such an error during the
run of your program, once it has terminated you may 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 may 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 may 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 wish to recover from an error and to continue to run your
program, then 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 may wish 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
will need to 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 non-0 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 will terminate 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.