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