home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / fortran / 2999 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  1.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!haven.umd.edu!darwin.sura.net!jvnc.net!yale.edu!think.com!Think.COM!sandee
  2. From: sandee@Think.COM (Daan Sandee)
  3. Newsgroups: comp.lang.fortran
  4. Subject: Re: programming style question
  5. Date: 12 Aug 1992 20:13:25 GMT
  6. Organization: TMC
  7. Lines: 20
  8. Message-ID: <16brd5INN946@early-bird.think.com>
  9. References: <1992Aug12.193739.23817@news.Hawaii.Edu>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <1992Aug12.193739.23817@news.Hawaii.Edu>, tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:
  13. |> If OPENing standard output, what good is trapping an ERR= condition,
  14. |> because there is no output device to which an error message can be
  15. |> written?  Of course, one could use the STOP 'Error message here'
  16. |> construct to get around this problem.  
  17.  
  18. In some implementations, a STOP statement is written to stdout *and* stderr.
  19. Hopefully, an error on preconnecting stdout and stderr will be handled
  20. gracefully by the system. But I wouldn't advise a STOP message if you find
  21. a problem on stdout.
  22.  
  23. You can write an error message to any file (stderr is the obvious first
  24. choice). Normally, this would occur if stdout is redirected to a file and
  25. (a) the file is write protected or (b) the device is full (or something).
  26. More interesting is when you get an error on writing to stderr. Then there
  27. is no obvious solution.
  28.  
  29. Daan Sandee                                           sandee@think.com
  30. Thinking Machines Corporation
  31. Cambridge, Mass 02142                                 (617) 234-5044
  32.