Critical errors like an open disk drive or adisconnectedprinter result in the DOS message "Abort, Retry,Ignore,Fail?" without saving the current display, thusruining theapplication screen.
Turbo Pascal 4.0 allows you to write procedures whicharelabelled INTERRUPT which automatically save all theregistersand restore them when returning. In addition, youcan modifythe registers within the procedure, and thosechanges arepassed back to DOS. No more need for routineswritten inassembler !
I have used this new ability of TP4 to write acriticalerror handler unit. When it is incorporated intheapplication it will save the screen, ask for a response,passthe response back to DOS, and restore theapplication'sscreen intact.
Beginning with DOS 3.0 the DOS technical referencesaysyou should not code to correct specific errors, eventhoughyou can present a message which is quite specific. Instead,you are told to follow the suggested action indicatedby DOSthrough INT 59h, GetExtError. This is now thepreferredmethod of error trapping according to the BlueBible. Theregisters will also let you know the location ofthe error,generally, and the type of error, generally, asshown below.
Other critical error handlers in the public domaindon'tuse this format probably because it is only useful forthosewho use DOS 3.x. This program checks the DOS versionand ifit is < 3.x finds the DOS error number by looking atlo(DI)which contains the old DOS critical error number andthenconverts it to the new extended error numbers by adding19 toit. It then extracts what other information it can fromtheregisters. You can then use the error message pointed tobythe resulting number, and the other information, butyoudon't get a suggested correction, you may getunexpectedanswers in the future, and you transgress.
See the program listing for the specific codes andtheirmeanings.
Other methods are available for dealing with errorsaswell. They are included in the unit.
You can disable IO checking and call IOResult,thenhandle the error in a more specific way than justallowingabort retry ignore fail. If you use the INT24 unitfrom theEditor Toolbox you can trap critical errors this wayas well,and take specific action to correct the situation.
Finally, you should have an exitprocedure to clean upandto catch errors you otherwise wouldn't expect, likeheap spaceerrors. That's here too.ß▄ßj ß▄ßßîß▄j ▄î Printer Errors are another story. Although theprinterif off will trigger INT24h, if it is only off line orout ofpaper, no trap takes place. I've included a check fortheprinter status in the code using INT 17h which may beuseful. Be careful though, because NONE of these traps anerror withmy HP ThinkJet. Most other printers I've triedrespond asexpected.
Another value of the program is the use of the heaptostore the error messages. Although TP4 allows multiplecodesegments so that code can exceed 64K, it still onlyallowsone data segment, and so only 64K of data. Inaddition,typed constants have been moved to the data segmentas well,so that older trick of hiding them in the codesegment nolonger works. To overcome this limitation it isnecessary to use the heap to store data. That is why I choseto use thepointer structure to hold the long list of errormessages.
Thanks to a suggestion by Scott Bussinger, this revisionremoves dependence on TP4 read and write procedures and colorsettings, and windowing functions.
Using the TP4 procedures resets certain constants likeIOResult, and can result in the system hanging. In addition,the use of the pointer method of screen swapping in theearlier version results, on an IBM color card, in snow on thescreen. Finally, the earlier version didn't keep track ofthe cursor position of the prior screen, so that the state ofthe screen on return was unpredictable.
I have used a variety of routines picked up from otherusers of this forum to overcome some of these problems, andthey are in the include files used. They are valuable inother situations as well.
