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