Hi holger I got confused. There is a problem with next: not raising error? Stef On 29/8/14 09:16, Holger Hans Peter Freyther wrote:
Hi,
while writing some SMS PDU parsing code I stumbled across an "oddity" I have not seen with GNU Smalltalk. When calling the
#next: selector on a ReadStream and the number of elements I need are not available, Pharo will return less or an empty collection. This means I write code like this:
| id len | id := stream next: 4 id size = 4 ifFalse: [^self reportError: 'Short read'].
len := stream next: 4 len size = 4 ifFalse: [^self reportError: 'Len not available'].
Besides the aesthetic issue it is getting worse when the SocketStream class is in use. So now >>#next: 4 can return nil as well. But naively I wrote code like this:
[ | msg | msg := ThingParser parse: aSocketStream. ] on: ConnectionClosed do: [:e | self logStuff: e. self scheduleReconnect ]
So to make the above code work with the SocketStream I need to write the following. I had a quick look at why the ConnectionClosed is swallowed and found the comment to allow partial reads out of a dead socket.
| id len | id := stream next: 4. id ifNil: [^self reportError: 'Short read'].
len := stream next: 4 len ifNil: [^self reportError: 'Short read']. len size = 4 ifFalse: [^self reportError: 'Len not available']
In GNU Smalltalk there is EndOfStream which is a subclass of Notification and the above code boils down to:
[ | id len | id := stream next: 4. len := stream next: 4. ] on: EndOfStream do: [:e | self logStuff: e. self scheduleReconnect. ].
So couldn't the >>#readInto:startingAt:count: selector of SocketStream do something like GNU Smalltalk and give an EndOfStream notification?
[self receiveData: anInteger] on: ConnectionClosed do:[:ex| EndOfStream signalOn: self. ex return ].
kind regards holger