EndOfStream an Error???

Raab, Andreas Andreas.Raab at disney.com
Wed May 24 19:32:32 UTC 2000


Bob wrote:
> Do you have an example that's a little more realistic? I was 
> wondering what the effect would be on typical code, so I made 
> a change to count the number of times that EndOfStream was 
> actually signalled. Then I browsed around for a while and 
> when I checked the number, it was still zero! So, I thought, 
> filing in some code ought to do it. Nope - still zero. It 
> wasn't until I evaluated "(ReadStream on: '1') nextChunk" 
> that I actually got a hit. Hmm...

Good point. No, I don't have a realistic example. Mainly because I don't
know who is really relying on #next quickly returning nil in what cases.
What I do know, however, is that not too long ago we've integrated a change
set (I think from Bert) which modified quite some places to use the
#next/#isNil test instead of #atEnd. Which leads me to the assumption that
there ought to be places in which a quick return might be really critical.

John wrote:
> 
> What is wrong with having EndOfStream be an error?
> 

Nothing. It's just a question of definition. As of now, EndOfStream is
usually not treated as an error, but it silently returns nil. But if it is
an error, then having the default action to return nil is just not right -
it ought to raise an error notifier if not handled. If it's a notification
(to whomever) then returning nil is fine. Although even in this case it is
probably a Very Good Idea to check the senders of #next/#isNil pairs since
the speed of any #next operation at the end of a stream depends on the stack
depth (due to the time the exception mechanism needs to search the stack for
a handler). And this can be expensive in cases where you'd least expect it.

  - Andreas





More information about the Squeak-dev mailing list