Sorry to pop in late in the game. I haven't followed all of this thread.
Fixing up all senders of #next is certainly not the simplest possible
thing that can work. Given that each kind of exception can have its own
default handler raises the following question in my mind.

What is wrong with having EndOfStream be an error?

It would be necessary for this exception to define its default handler
action to return nil. This would preserve the semantics of non-exception
aware code while simultaneously making it  possible for exception aware
code to trap the exception and handle it in new and novel ways.

My quatre sous,
John Sarkela

> 
> At 23:23 23.05.2000 -0700, Andreas Raab wrote:
>> Just wondering: Who came up with the idea that EndOfStream is an error?!
> 
> I'm the one to be blamed here.
> 
> At 01:32 24.05.2000 -0700, Andreas Raab replied to Paul McDonough:
>>> It seems like EndOfStream could just as well be implemented as a
>>> Notification ... ?
>> 
>> Perhaps yes. Perhaps no. It seems to me that the entire issue is going a bit
>> deeper. EndOfStream *could* really mean an Error - that is representing
>> something like an attempt to read beyond the elements stored in the stream.
>> But then, we really need to fix up all the users of #next which rely on a
>> quick nil return for past-end reads.
> 
> I am (slowly, however) working through this- Bob Arning already provided a
> couple of pointers into #next's senders list,
> 
> PositionableStream>>upToEnd
> Base64MIMEConverter>>nextValue
> DataStream>>next
> 
> and, as you kindly pointed out,
> 
> StandardFileStream>>peekFor: (cf. PositionableStream>>peekFor:)
> PositionableStream>>nextDelimited:
> PositionableStream>>nextChunk
> PositionableStream>>next:into:startingAt:
> InflateStream>>next:into:startingAt:
> 
> plus
> 
> String>>unescapePercents
> CrLfStream>>upTo:
> FlashFileStream>>nextByteForBits
> FreeCellBoard>>resetStacks
> 
> and probably quite a couple of places more.  GIFReadWriter>>nextByte I'll
> have to at least look at, too.
> 
> BTW, I'm using the results of
> 
> "this takes a while..."
> | testers senders both |
> testers _ #(isNil notNil ifNil: ifNotNil:
> ifNil:ifNotNil: ifNotNil:ifNil:
> == = ~= ~~)
> inject: OrderedCollection new
> into: [:accum :each | accum addAll: (Smalltalk allCallsOn: each);
> yourself].
> testers _ testers asSet.
> senders _ Smalltalk allCallsOn: #next.
> both _ (senders select: [:any | testers includes: any]) asSortedCollection.
> MessageSet openMessageList: both
> name: 'next and nil (', both size printString, ')'
> autoSelect: both first
> "---"
> 
> but this only reduces the list to 199 candidate methods.  I'm pretty much
> tied up for the upcoming weekend, so progress is slow.
> 
>> So, from my point of view we have two options: a) We can rely on a quick
>> return nil from #next. That means no EndOfStream, which would require a bit
>> more effort when porting stuff from other ST80 dialects.
> 
> We might push this change to 2.9a, until the senders of #next are
> fixed.  We could simply revert ReadStream>>next to its previous version for
> now.  Opinions, QC?
> 
>> b) We define a
>> past-end read operation as an error. That means leaving EndOfStream as an
>> error and fix up those clients that do implicitly handle EndOfStream by
>> testing for nil. Both are valid options but b) will change a lot of
>> fundamental code and require a coordinated effort to fix up all the senders
>> of #next.
> 
> Too true.
> 
> To my dismay, this cs had a more widespread effect than I had hoped.  It
> may just not be ready for prime time without the sender fixes.  So, I can
> live with reverting for now, but I still think it'll make a worthwhile
> addition.  Once it's ready.
> 
> My apologies for causing overtime,
> Helge
>