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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d8a4797a79f9c90f
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-05-28 00:51:02 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!news-FFM2.ecrc.net!news.cesnet.cz!crax.cesnet.cz!news.felk.cvut.cz!not-for-mail
From: Sergey Koshcheyev <serko84@hotmail.com>
Newsgroups: comp.lang.ada
Subject: Re: I/O - exception handling
Date: Wed, 28 May 2003 09:33:17 +0200
Organization: Czech Technical University
Message-ID: <bb1oo9$1l6q$1@ns.felk.cvut.cz>
References: <bat3ee$2ec$1@ns.felk.cvut.cz> <bauf7t$tei$1@ns.omskelecom.ru>
 <3ED4114A.5060204@spam.com>
NNTP-Posting-Host: r2c113.mistral.cz
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: ns.felk.cvut.cz 1054107209 54490 62.245.66.113 (28 May 2003 07:33:29
 GMT)
X-Complaints-To: usenet@ns.felk.cvut.cz
NNTP-Posting-Date: Wed, 28 May 2003 07:33:29 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030520
X-Accept-Language: en, ru, cs
In-Reply-To: <3ED4114A.5060204@spam.com>
Xref: archiver1.google.com comp.lang.ada:37876
Date: 2003-05-28T09:33:17+02:00
List-Id: <comp.lang.ada>

Jeffrey Carter wrote:
> I'm not sure what all the fuss is about. Close can only raise 
> Status_Error, and only if the file is not open (ARM A.8.2).

Is it really so? The ARM says (regarding Close):

"The exception Status_Error is propagated if the given file is not open."

I'm not a language lawyer, but I don't think this sentence forbids any 
other behavior (like Device_Errors or Use_Errors).

 > Is_Open may not raise an exception (ARM A.8.2).

ARM A.8.2 (29) also says:

"An implementation may propagate Name_Error or Use_Error if an attempt 
is made to use an I/O feature that cannot be supported by the 
implementation due to limitations in the external environment. Any such 
restriction should be documented."

Since Is_Open is an I/O feature, this means to me that it may raise one 
of these exceptions too.

Or am I being way too "legal"?

> So the pattern
> 
> begin
>    Open (File, ...);
> 
>    -- Process File
> 
>    Close (File);
>    -- If Open failed, we do not get here, so this cannot
>    -- raise an exception
> exception
> when others =>
>    if Is_Open (File) then
>       Close (File);
>    end if;
> end;
> 
> is completely safe.

This has "Close (File)" in two places, so it is also against the "do 
everything only once" principle.

Maybe my requirements are too hard and unrealistic, but anyway, I have 
already found an almost perfect solution, described in one of my earlier 
posts (where I ignore errors from Close).

Sergey.