Contents of the TESTERR.DOC file
Critical errors like an open disk drive or a
disconnected printer result in the DOS message "Abort, Retry,
Ignore, Fail?" without saving the current display, thus
ruining the application screen.
Turbo Pascal 4.0 allows you to write procedures which
are labelled INTERRUPT which automatically save all the
registers and restore them when returning. In addition, you
can modify the registers within the procedure, and those
changes are passed back to DOS. No more need for routines
written in assembler !
I have used this new ability of TP4 to write a critical
error handler unit. When it is incorporated in the
application it will save the screen, ask for a response, pass
the response back to DOS, and restore the application's
Beginning with DOS 3.0 the DOS technical reference says
you should not code to correct specific errors, even though
you can present a message which is quite specific. Instead,
you are told to follow the suggested action indicated by DOS
through INT 59h, GetExtError. This is now the preferred
method of error trapping according to the Blue Bible. The
registers will also let you know the location of the error,
generally, and the type of error, generally, as shown below.
Other critical error handlers in the public domain don't
use this format probably because it is only useful for those
who use DOS 3.x. This program checks the DOS version and if
it is < 3.x finds the DOS error number by looking at lo(DI)
which contains the old DOS critical error number and then
converts it to the new extended error numbers by adding 19 to
it. It then extracts what other information it can from the
registers. You can then use the error message pointed to by
the resulting number, and the other information, but you
don't get a suggested correction, you may get unexpected
answers in the future, and you transgress.
See the program listing for the specific codes and their
Other methods are available for dealing with errors as
well. They are included in the unit.
You can disable IO checking and call IOResult, then
handle the error in a more specific way than just allowing
abort retry ignore fail. If you use the INT24 unit from the
Editor Toolbox you can trap critical errors this way as well,
and take specific action to correct the situation.
Finally, you should have an exitprocedure to clean up
and to catch errors you otherwise wouldn't expect, like
heap space errors. That's here too.j
Printer Errors are another story. Although the printer
if off will trigger INT24h, if it is only off line or out of
paper, no trap takes place. I've included a check for the
printer status in the code using INT 17h which may be useful.
Be careful though, because NONE of these traps an error with
my HP ThinkJet. Most other printers I've tried respond as
Another value of the program is the use of the heap to
store the error messages. Although TP4 allows multiple code
segments so that code can exceed 64K, it still only allows
one data segment, and so only 64K of data. In addition,
typed constants have been moved to the data segment as well,
so that older trick of hiding them in the code segment no
longer works. To overcome this limitation it is necessary to
use the heap to store data. That is why I chose to use the
pointer structure to hold the long list of error messages.