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!attcan!uunet!lll-winken!lll-lcc!ames!ucsd!rutgers!rochester!pt.cs.cmu.edu!sei!jbg
From: jbg@sei.cmu.edu (John Goodenough)
Newsgroups: comp.lang.ada
Subject: Exceptions raised by I/O operations
Message-ID: <8104@aw.sei.cmu.edu>
Date: 4 Jan 89 16:02:20 GMT
Followup-To: Re: Ada/UNIX(tm) and the NAME function
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
List-Id: <comp.lang.ada>


Robert Firth said in a recent post:

>>   5.  The error cannot be deferred to the actual use of NAME because
>>   NAME is not defined as being able to raise any exception except
>>   STATUS_ERROR and it may only do that if the file is not open.

>No: the fact that it is required to raise an exception does not imply
>(here or elsewhere) that it is forbidden to raise any otehr exception.

This remark was questioned by Stephe Leake who said:

>  This sounds dangerous to me; I have always assumed that the
>  pre-defined packages behaved _precisely_ as specified in the LRM,
>  _including_ which exceptions may be raised. Thus, if the LRM does not
>  state that a particular routine may raise an exception, it should not
>  do so. This is critical in writting exception handlers; we have to
>  know which exceptions a routine may raise in order to handle them all.

and John Stafford, who asked:

>  I also am not "Ada knowledgeable" enough to know that it is OK for
>  routines which the RM defines as able to raise some exceptions to
>  raise others as well.  I would genuinely appreciate references to why
>  this is OK (at first glance it would seem to me to make an
>  implementation of Ada non-conformant if use of NAME could raise
>  NAME_ERROR).

Robert is literally correct, but his remark is subject to misinterpretation.
14.1(11) says:

	The exceptions that can be raised by a call of an input-output
	subprogram are all defined in the package IO_EXCEPTIONS; the
	situations in which they can be raised are described, either following
	the description of the subprogram (and in section 14.4), or in
	Appendix F in the case of error situations that are
	implementation-dependent. 

This paragraph does not exclude the possibility that other exceptions can be
raised as well, and in fact, this is possible:

	NEW_LINE(-1);

will raise CONSTRAINT_ERROR because the argument does not belong to the formal
parameter's subtype.  NUMERIC_ERROR, TASKING_ERROR, PROGRAM_ERROR, or
STORAGE_ERROR could similarly be raised as a result of evaluating the argument
to an I/O subprogram.  PROGRAM_ERROR and STORAGE_ERROR might be raised by the
body of an I/O subprogram.  (PROGRAM_ERROR could be raised by an attempt to
PUT an uninitialized array variable, for example.)  AI-00279 addresses this
situation by saying:

	After execution of the body of an input-output subprogram has started,
	the only exceptions that can be propagated to the caller are the
	exceptions defined in the package IO_EXCEPTIONS and the exceptions
	PROGRAM_ERROR and STORAGE_ERROR.

This means the evaluation of an argument can raise any exception, but the
subprogram itself is limited in what it can raise.

Although the wording is still not completely precise, it seems clear to me
that the intent is that NAME not raise NAME_ERROR in any case.  If a name
cannot be determined because a parent directory can't be opened, I would say
that USE_ERROR should be raised.

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