comp.lang.ada
 help / color / mirror / Atom feed
From: jbg@sei.cmu.edu (John Goodenough)
Subject: Re: Exceptions raised by I/O operations
Date: 6 Jan 89 16:52:51 GMT	[thread overview]
Message-ID: <8122@aw.sei.cmu.edu> (raw)


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

             reply	other threads:[~1989-01-06 16:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1989-01-06 16:52 John Goodenough [this message]
  -- strict thread matches above, loose matches on Subject: below --
1989-01-04 16:02 Exceptions raised by I/O operations John Goodenough
1989-01-05 18:10 ` John Stafford
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox