home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / pascal / 4891 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  2.5 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!canterbury.ac.nz!cctr132
  2. Newsgroups: comp.lang.pascal
  3. Subject: Re: Problems with IOResult (TP.6)
  4. Message-ID: <1992Aug18.173012.394@csc.canterbury.ac.nz>
  5. From: cctr132@csc.canterbury.ac.nz (Nick FitzGerald, CSC, Uni. of Canterbury, NZ)
  6. Date: 18 Aug 92 17:30:11 +1200
  7. References: <h07mcp=.gabriel@netcom.com> <sbarr.1.714023372@nyx.cs.du.edu>
  8. Organization: University of Canterbury, Christchurch, New Zealand
  9. Lines: 42
  10.  
  11. In article <sbarr.1.714023372@nyx.cs.du.edu>, sbarr@nyx.cs.du.edu
  12. (Sam E. Barr) writes:
  13.  
  14. [original problem description from gabriel@netcom.com deleted]
  15. > The problem here is that TP store the IOResult variable until you read it, 
  16. > after which it clear it.  So if you make a call to a function which returns
  17. > a non-zero IOResult, and then call another i/o function without first
  18. > reading, and thus clearing IOResult, you still get a non-zero result,
  19. > regardless of the result of the second function.
  20.   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  21. Come on Sam - if we are going to help, let's at least get it right. 
  22.  
  23. I've never used TP 6, but for all versions from 3.01 to 5.5 inclusive,
  24. with I/O checking off, if a standard TP I/O function is about to be
  25. called and IOResult is non-zero (or, at least positive ?) that function
  26. is -skipped-.  The compiler builds code with I/O checking on to generate
  27. a run-time error on an I/O error and with checking off to ensure that no
  28. further I/O is done (with possibly disastrous effects) until IOResult
  29. has been cleared (it is assumed that the programmer knows what s/he is
  30. doing and takes the appropriate action, given the reported error).
  31.  
  32. > The other problem arrising from this is that you cannot use a call such as
  33. > 
  34. >    if IOResult <> 0 then
  35. >      if IOResult = 8 then ....
  36. > 
  37. > because the IOResult is cleared after you read it the first time, and thus 
  38. > will be zero for the next read.
  39.  
  40. This is -clearly- documented, and I would hope anyone contemplating
  41. writing their own I/O error handling read this and other relevant parts
  42. of the Manuals/References very carefully before embarking.
  43.  
  44. > I'll leave it up to you to decide whether this is a bug or a feature, but 
  45. > for my mind it is a pain in the neck either way!!   :(
  46.  
  47. Given the above, you may now understand why this feature was designed
  48. thus.  Why do you expect error-handling to be easy?
  49.  
  50. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  51.  Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
  52.  n.fitzgerald@csc.canterbury.ac.nz  (64)(3)  364-2337 Voice,  364-2332 FAX
  53.