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.