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.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!rutgers!rochester!pt.cs.cmu.edu!sei!jbg
From: jbg@sei.cmu.edu (John Goodenough)
Newsgroups: comp.lang.ada
Subject: Re: Exceptions raised by I/O operations
Message-ID: <8122@aw.sei.cmu.edu>
Date: 6 Jan 89 16:52:51 GMT
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
List-Id: <comp.lang.ada>


John Stafford writes:

> 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.  

My intention was that NAME should raise USE_ERROR if it can't return a result.
I don't see any justification for OPEN/CREATE to raise any exception based on
whether NAME can return a result, and in fact, AI-00046 notes that CREATE for
a temporary file is expected to succeed even when NAME cannot return any
result because the file has no usable name.

> If NAME should raise USE_ERROR then I can't find strong
> objection to it raising NAME_ERROR either, ...

The reason NAME can't raise NAME_ERROR is that 14.4(4) indicates that the only
operations allowed to raise NAME_ERROR are OPEN and CREATE.  14.4(5) says
USE_ERROR can be raised by any operation, so it can be raised by NAME.  Moreover,
AI-00046 points out that "the NAME function is allowed to raise USE_ERROR if
its argument is associated with an external file that has no name, in
particular, a temporary file" might have no name in some operating systems.


> ... 14.1(11) ... 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?

No.  The implementation-dependent situations referred to in 14.1(11) are those
that complete the definitions given in 14.4, e.g., the situtations under which
NAME_ERROR will be raised by CREATE or OPEN, the situations when USE_ERROR is
raised by any operation, etc.  "Implementation-dependent" should not be read
as saying any exception can be raised by any operation -- 14.4 says what
exceptions can be raised by the operations, but is necessarily non-specific
about all the implementation-dependent situations that satisfy the conditions
described there.  14.1(11) means Appendix F should give the additional details.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391