From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!oberon!sm.unisys.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpcljws!jws
From: jws@hpcljws.HP.COM (John Stafford)
Newsgroups: comp.lang.ada
Subject: Re: Exceptions raised by I/O operations
Message-ID: <920007@hpcljws.HP.COM>
Date: 5 Jan 89 18:10:34 GMT
References: <8104@aw.sei.cmu.edu>
Organization: Hewlett-Packard Calif. Language Lab
List-Id: <comp.lang.ada>

The information that is accumulating is all useful, but as usual, it
seems that the more I learn the more questions I have.

John Goodenough indicates that his interpretation is that NAME should
not raise NAME_ERROR and if the name cannot be determined that USE_ERROR
be raised.  I'm sorry that it isn't clear to me whether he means that
the OPEN/CREATE call should raise USE_ERROR if it determines that the
NAME will not be determinable or that NAME should raise USE_ERROR.

If OPEN/CREATE should raise USE_ERROR it seems to unfairly penalize the
user, who may not ever want or need the name, but who can open and use
the file.  If NAME should raise USE_ERROR then I can't find strong
objection to it raising NAME_ERROR either, as STATUS_ERROR is the only
exception that it is specified as being able to raise (granted neither
USE_ERROR nor NAME_ERROR really indicates what is wrong and perhaps
USE_ERROR is a "closer" error than NAME_ERROR and hence is to be
preferred).  In either case, I suspect that Appendix F should indicate
that whatever exception is raised can be due to an inability to
determine the name even though the file may be perfectly accessible to
the user.

Thanks to John Goodenough for pointing out 14.1(11) which actually makes
these waters slightly muddier as well.  One could interpret "the
situations in which they can be raised are described, ..., or in
Appendix F in the case of error situations that are
implementation-dependent" as indicating that any I/O call could raise
any I/O exception in an "implementation dependent error situation".  Is
that a potentially reasonable interpretation?

--
John Stafford -- Hewlett Packard California Language Lab
{allegra,decvax,ihnp4,ucbvax}!hplabs!hpda!jws
{fortune,sun,thirdi,ucbvax}  !hpda  !jws