David,

> >Well, BSD sockets uses -1 instead of Error, but it's the same idea.  You
> >have to just try your read() or write() and then check whether it
> >worked.
> >  
> 
> I'm not so sure about that.  A read on a socket closed on the other end 
> should return "zero bytes" to the best of my recollection.  Also, I 
> don't agree that its the same idea.  The sockets version "returns" a 
> useful error code, squeak burries it in a generic exception and the 
> "Socket>>socketError" mechanism (which appears to be unused and unusable 
> due to the question of what "the last socket error" really means since I 
> can't tell if there was really a socket error or if the primitive failed 
> because it couldn't find my Aunt Mary's phone number).  As I think I 
> stated quite clearly, the problem isn't the socket error handling 
> mechanism, it's squeak's abstraction on it.  There's probably some 
> patchwork one can do to fix this up...again, I just needed to know if I 
> was missing something.

  But, you, err, the user of Socket, have to take care of the error
conditions accordingly.  The low-level code (Socket and SocketStream)
cannot know what would be the right thing to do on errors because it
is application specific.

  There is no guard predicates to ensure the subsequent #sendData: or
such succeeds as the socket status can be changed after the guard test
and before #sendData:.  So, the 'fix' to the guard predicate in
SocketStream>>flush won't 'fix' the whole situation.

> >IMHO, the best immediate "fix" is to be sure that proper exceptions are
> >used so that you don't have to catch the generic Error.
> >
> 
> 
> Bingo.  That's what I'll have to do...assuming it is even possible based 
> on the existing plugin code.  I haven't looked at it, in fact I'm afraid to.

  What I'd do is to handle the ConnectionTimedOut exception and the
other kind of exception differently if needed.

  I'm curious what kind of different actions we could take for
different type of errors.

> >Also, this area horribly needs some documentation.
> >
> >	1. The proper error handling approach should be described somewhere.
> >	
> >	2. The semantics of close should be documented.  At least on Unix, it
> >means "I promise not to send any more data".  It is perfectly allowed to
> >#close and then #receiveData: however.

> Yes and yes!  So squeak's close is sockets 1/2 close (shutdown)
> operation?  That's interesting and yes, it should be documented
> since it is quite unexpected.

  It looks like so.  It confuses me, too.

-- Yoshiki