End of File for streams

End of File for streams

[Kevin Rigotti]

Given an input file accessed via T'Read() on the associated
stream access value, is there a clean way to determine end of file?

All I have at the point of need is the stream access value
not the File_Type object that it was obtained from so I can't
just use Ada.Streams.Stream_IO.End_of_File or compare Index()
with Size().

The file has more than one data type in it, read in different
parts of the source code, so keeping track of how much I've read
is not trivial.

I have philosophical and aesthetic objections to trapping the
End_Error exception as a means of determining end of file, but
is this the only way to do it?

Kevin

Re: End of File for streams

[Gautier]

Kevin Rigotti wrote:

> I have philosophical and aesthetic objections to trapping the
> End_Error exception as a means of determining end of file, but
> is this the only way to do it?

Other possible advantages of using the exception:

  - you can stream-in data from an "endless" stream as well (not
    only a Stream_IO file)
  - I have noticed much faster data transfers using the exception
    variant - mainly with GNAT and also with Direct_IO, surely
    due to the fact it reduces some checks around EOF.

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: End of File for streams

[Robert Dewar]

In article <8df15j$e4b$1@trog.dera.gov.uk>,
  "Kevin Rigotti" <rigotti@atc.dera.gov.uk> wrote:
> I have philosophical and aesthetic objections to trapping the
> End_Error exception as a means of determining end of file, but
> is this the only way to do it?

It's always odd when you have a situation where Ada provides
an approach X to solving problem Y that works in a perfectly
straightforward manner, and then asks

How can I do Y without using X, because I don't want to use X.

That's the situation you are in here. Catching End_Error is a
clean solution to your problem and is the recommended approach.
It is also often the more efficient approach compared to an
explicit end of file test in the loop.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: End of File for streams

[Brian Rogoff]

On Mon, 17 Apr 2000, Robert Dewar wrote:

> In article <8df15j$e4b$1@trog.dera.gov.uk>,
>   "Kevin Rigotti" <rigotti@atc.dera.gov.uk> wrote:
> > I have philosophical and aesthetic objections to trapping the
> > End_Error exception as a means of determining end of file, but
> > is this the only way to do it?
> 
> It's always odd when you have a situation where Ada provides
> an approach X to solving problem Y that works in a perfectly
> straightforward manner, and then asks
> 
> How can I do Y without using X, because I don't want to use X.
> 
> That's the situation you are in here. Catching End_Error is a
> clean solution to your problem and is the recommended approach.
> It is also often the more efficient approach compared to an
> explicit end of file test in the loop.

I agree that catching End_Error is the correct solution, but in Kevin's 
defense, many (Ada) programmers are taught that exceptions are only for 
error processing and not control flow, and giving the exception a name 
like "End_Error" rather than, say, "End_Of_Stream" doesn't help matters
any. 

-- Brian

Re: End of File for streams

[Gautier]

Kevin Rigotti wrote:

> I have philosophical and aesthetic objections to trapping the
> End_Error exception as a means of determining end of file, but
> is this the only way to do it?

A complement...

- Philosophical ? Is it less tangible or don't you believe it will
work ? No problem, the Manual _guarantees_ that End_Error will be raised
at time!

- Aesthetic ?
    ...
    begin
      for i in inbuf'range loop
        Read( infile, inbuf(i) );
        readpos:= readpos + 1;
      end loop;
    exception
      when End_Error => null;  -- nothing, we just reached EOF
    end;
    ...

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: End of File for streams

[Robert I. Eachus]

Kevin Rigotti wrote:
> 
> OK, its nice to have some external confirmation occasionally. I don't get to
> see much code written by other people here ...
> 
> In my own defence (but thanks Brian)
> 1) as an impressionable undergrad I was brought up on a diet of functional
> programming so using exceptions for control flow seems decadent :-)
> 
> 2) I don't like using exceptions for non-exceptional behavior. Just a
> personal foible.

    The "normal" Ada design for reading entries from a file uses the
End_Error exception as an exception, while correct data results in an
exit due to End_Of_File:

   while not End_Of_File(Input_File) loop
     begin
       Get_Item_1;
       Get_Item_2;
       Get_Item_3;
     exception
       when End_Error | Data_Error | Device_Error =>
          Correct_Partial_Entry;
       when others =>
          ...
     end;
   end loop;

   Reading a character at a time is a degenerate case, and you can do
that either way.  I guess it is not considered a major issue in Ada,
since the expected behavior is to read data in larger chunks.  (Stream
files are a different situation, and there the expected behavior when
you run out of data is to wait for more. ;-)

Re: End of File for streams

[Kevin Rigotti]

OK, its nice to have some external confirmation occasionally. I don't get to
see much code written by other people here ...

In my own defence (but thanks Brian)
1) as an impressionable undergrad I was brought up on a diet of functional
programming so using exceptions for control flow seems decadent :-)

2) I don't like using exceptions for non-exceptional behavior. Just a
personal foible.

I've changed my mind about the aesthetic objection. It doesn't look that bad
actually.

Thanks

Kevin

Re: End of File for streams

[Robert Dewar]

In article <8dg55l$us3$1@trog.dera.gov.uk>,
  "Kevin Rigotti" <rigotti@atc.dera.gov.uk> wrote:
> OK, its nice to have some external confirmation occasionally.
I don't get to
> see much code written by other people here ...
>
> In my own defence (but thanks Brian)
> 1) as an impressionable undergrad I was brought up on a diet
of functional
> programming so using exceptions for control flow seems
decadent :-)
>
> 2) I don't like using exceptions for non-exceptional behavior.
Just a
> personal foible.


You need to have the right view of what non-exceptional
behavior means.

For the loop doing the reading, the EOF *is* an exceptional
case, since the read fails.

At one level of abstraction higher, this is not an exceptional
situation, which is why we handle it locally at the lower
level of abstraction, and then do not propagate the exception
to a higher level.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: End of File for streams

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 465 bytes --]

On Tue, 18 Apr 2000, Jean-Pierre Rosen wrote:
> Kevin Rigotti <rigotti@atc.dera.gov.uk> a écrit dans le message :
> 8dg55l$us3$1@trog.dera.gov.uk...
> > 2) I don't like using exceptions for non-exceptional behavior. Just a
> > personal foible.
> >
> But it IS exceptional behavior!

Agreed. 

> Exceptions are not called "errors". 

Refresh my memory then. What is the name of the exception which signals 
the end of a stream? :-)

-- Brian

Re: End of File for streams

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 744 bytes --]


Kevin Rigotti <rigotti@atc.dera.gov.uk> a �crit dans le message :
8dg55l$us3$1@trog.dera.gov.uk...
> 2) I don't like using exceptions for non-exceptional behavior. Just a
> personal foible.
>
But it IS exceptional behavior!
Exceptions are not called "errors". Exceptional processing is when you
cannot continue with "normal" processing (i.e., an exception to the rule).
Typically, you have a loop, and you encounter a situation that forces you to
make something different from the regular loop processing. Seems to me that
the end of file typically fits this situation.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: End of File for streams

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]


Brian Rogoff <bpr@shell5.ba.best.com> a �crit dans le message :
Pine.BSF.4.21.0004180935170.25887-100000@shell5.ba.best.com...
>On Tue, 18 Apr 2000, Jean-Pierre Rosen wrote:
>> Exceptions are not called "errors".
>
>Refresh my memory then. What is the name of the exception which signals
>the end of a stream? :-)
But of course,  errors are one kind of exceptions...

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: End of File for streams

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 784 bytes --]

On Tue, 18 Apr 2000, Jean-Pierre Rosen wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> a écrit dans le message :
> Pine.BSF.4.21.0004180935170.25887-100000@shell5.ba.best.com...
> >On Tue, 18 Apr 2000, Jean-Pierre Rosen wrote:
> >> Exceptions are not called "errors".
> >
> >Refresh my memory then. What is the name of the exception which signals
> >the end of a stream? :-)
> But of course,  errors are one kind of exceptions...

Right, but my point is that the name choice "End_Error" was a very bad one 
because this exception is not likely an error, but simply the exceptional
case of the stream being out of data. 

In my favorite "functional" language, this case is signalled by an
exception named "End_of_file" which is a better name IMO. 

-- Brian