Re: Sample code for I/O ideas

[James Knight <jknight@xxxxxxxx>]

I know there's two schools of thought on this, but I believe exceptions 
should (at least in most cases) only be used for *exceptional* 
conditions. Exceptions should not be used for indicating EOF, or for 
indicating end-of-iterator, or anything like that where you *know* it's 
going to happen. For instance, you could write a loop over an array as:
(dv v #(1 2 3))

(esc break
   (try <range-error> (fun (c r) (break #f))
     (rep loop ((i 0))
       (post "%s\n" (elt v i))
       (loop (+ i 1)))))

but that's very ugly to me. But, I bring up this particular case 
(looping over an array), because, interestingly, you *can* write code 
with either explicit checking (< i (len v)) or by waiting for an 
exception to be thrown. Under some conditions where you know more about 
the expected structure of the array (e.g. maybe it's length is always a 
multiple of two and you put each pair of elements into some other 
structure), it might significantly simplify the code to assume that the 
array has certain elements and throw an exception if it doesn't.

So, it's possible that for consistancy, a similar situation should 
occur with the stream functions. That is, normally, in a loop, you 
would write
(until (eof? port)
   ...(gets port)...)

But, if for whatever reason, in your code you didn't check for EOF, the 
next stream reading call should throw an exception. That is, any I/O 
call that would return no data because the stream is at EOF should 
throw an exception if read. Block reads such as gets/etc should still 
be allowed to return less data than requested without throwing an 
exception; only if they would return no data because of EOF should an 
exception be thrown. (note that if we support non-blocking streams in 
the future, the calls might return no data *not* because of EOF so 
don't just check for length=0)

So in conclusion, basically I agree with smelly's conclusion.

James

On Tuesday, November 19, 2002, at 08:02  AM, Smelly Pooh wrote:

> I've put together examples of how a unix cat function would look like 
> in
> the current scheme and each of the proposed schemes.
...
> My preference is leaning toward using exceptions, it'll be great if 
> both
> that and the current scheme can work together, I don't know how that'll
> work as you add more I/O methods such as block reads and writes or even
> asynchronous I/O, will methods be written for both schemes or will one
> take precedence?