Path: utzoo!mnetor!uunet!husc6!hao!ames!hc!beta!unm-la!unmvax!nmtsun!hydrovax From: hydrovax@nmtsun.nmt.edu (M. Warner Losh) Newsgroups: comp.lang.c Subject: Re: stdio error detection Message-ID: <1171@nmtsun.nmt.edu> Date: 16 Dec 87 03:28:31 GMT References: <10649@brl-adm.ARPA> <814@its63b.ed.ac.uk> Organization: NMT Hydrology program Lines: 29 Summary: Yes VMS does do this. It is really nice.... In article <814@its63b.ed.ac.uk>, simon@its63b.ed.ac.uk (ECSC68 S Brown CS) writes: > I'm told > that VMS (but it's a good idea for all that...) provides a stack of error > values which allows a program to search backward to find out what the "real" > error was, depending on what kind of detail is required. If you have several > levels of library calls between you and the system call that failed, this > can be extremely useful- it's not really much use having an error-value > if you can't even tell what system call it came from (let alone what parameters > were *passed* to that system call to cause it to fail!). VMS provides this facility AND a way of printing out the nested stack. For example, if a file can't be copied using the COPY command (unix types read cp) then you get something like %COPY-F-NOTCOPIED, File FOO.ARD;1 not copied -SYSTEM-F-READERR, Fatal read error in device. The second part varies tremendously, and can thus tell you that the file can't be copied because of file protection, or file lock, or a write error in the output, or ....... The point of all of this is that it makes error handling VERY EASY and almost ENJOYABLE. You know what wnet wrong where, and can usually do something half way intelligent about it. (But not always, alas....) -- bitnet: lush@nmt.csnet M. Warner Losh csnet: warner%hydrovax@nmtsun uucp: ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!warner%hydrovax ...{cmcl2, ihnp4}!lanl!unmvax!nmtsun!hydrovax Warning: Hydrovax is both a machine, and an account, so be careful.