home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / ERRTRP.ZIP / TESTERR.DOC < prev    next >
Encoding:
Text File  |  1988-02-27  |  3.3 KB  |  20 lines
  1.     Critical errors like an open disk drive or a
  2. disconnected printer result in the DOS message "Abort, Retry,
  3. Ignore, Fail?" without saving the current display, thus
  4. ruining the application screen.
  5.  
  6.     Turbo Pascal 4.0 allows you to write procedures which
  7. are labelled INTERRUPT which automatically save all the
  8. registers and restore them when returning.  In addition, you
  9. can modify the registers within the procedure, and those
  10. changes are passed back to DOS.  No more need for routines
  11. written in assembler !
  12.  
  13.     I have used this new ability of TP4 to write a critical
  14. error handler unit.  When it is incorporated in the
  15. application it will save the screen, ask for a response, pass
  16. the response back to DOS, and restore the application's
  17. screen intact.
  18.  
  19.     Beginning with DOS 3.0 the DOS technical reference says
  20. you should not code to correct specific errors, even though
  21. you can present a message which is quite specific.  Instead,
  22. you are told to follow the suggested action indicated by DOS
  23. through INT 59h, GetExtError.  This is now the preferred
  24. method of error trapping according to the Blue Bible.  The
  25. registers will also let you know the location of the error,
  26. generally, and the type of error, generally, as shown below. 
  27.     Other critical error handlers in the public domain don't
  28. use this format probably because it is only useful for those
  29. who use DOS 3.x.  This program checks the DOS version and if
  30. it is < 3.x finds the DOS error number by looking at lo(DI)
  31. which contains the old DOS critical error number and then
  32. converts it to the new extended error numbers by adding 19 to
  33. it.  It then extracts what other information it can from the
  34. registers.  You can then use the error message pointed to by
  35. the resulting number, and the other information, but you
  36. don't get a suggested correction, you may get unexpected
  37. answers in the future, and you transgress.
  38.  
  39.     See the program listing for the specific codes and their
  40. meanings.
  41.  
  42.     Other methods are available for dealing with errors as
  43. well.  They are included in the unit.
  44.  
  45.     You can disable IO checking and call IOResult, then
  46. handle the error in a more specific way than just allowing
  47. abort retry ignore fail.  If you use the INT24 unit from the
  48. Editor Toolbox you can trap critical errors this way as well,
  49. and take specific action to correct the situation.
  50.  
  51.     Finally, you should have an exitprocedure to clean up
  52. and to catch errors you otherwise wouldn't expect, like
  53. heap space errors.  That's here too.▄j▄î
  54.     Printer Errors are another story.  Although the printer
  55. if off will trigger INT24h, if it is only off line or out of
  56. paper, no trap takes place.  I've included a check for the
  57. printer status in the code using INT 17h which may be useful. 
  58. Be careful though, because NONE of these traps an error with
  59. my HP ThinkJet.  Most other printers I've tried respond as
  60. expected.
  61.  
  62.     Another value of the program is the use of the heap to
  63. store the error messages.  Although TP4 allows multiple code
  64. segments so that code can exceed 64K, it still only allows
  65. one data segment, and so only 64K of data.  In addition,
  66. typed constants have been moved to the data segment as well,
  67. so that older trick of hiding them in the code segment no
  68. longer works.  To overcome this limitation it is necessary to
  69. use the heap to store data.  That is why I chose to use the
  70. pointer structure to hold the long list of error messages. 
  71.