Socket connection signals ought to be handled?

I’m enjoying modernising some ScratchServer code and stumbling across a lot of changes made over the years. Sockets are not something I’m very knowledgable about so this is ‘fun’, for certain unusual definitions of the word.

As part of this ‘fun’ I notice that Socket>connectTo:waitForConnectionFor: (which uses Socket>waitForConnection:ifTimedOut:ifRefused:) may well raise one of two exceptions and that very few places seem to handle them, particularly a number of tests that I tried.

As an example , SocketStreamTest>setUp sends connectTo:port: which will end up using the standard timeout and may raise an exception; but the test code then explicitly does some wait method (which actually re-runs the very same lower-level code and may raise the same exceptions!) and other stuff. That looks to me like out of date code that will fail oddly with current Socket code. Tests and other examples really ought to be up to date and correct so we can rely upon them to work and to explain how to Do It Right.

As I say, I really don’t know Sockets. If someone loves Sockets and feels like fixing them up, I’d suggest starting by looking at senders of #connectTo:port: and spreading out from there. And maybe you could wave your hand and volunteer to help me out...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
M$ are grinning pigs in a sea of buggy code - The Inquirer

Your note is amusing.  Saying an exception is not handled, but not
saying what should be done by the handler.  Simultaneously admitting
not knowing about sockets and criticizing its "up-to-dateness".  I
guess you mean correctness.

> As an example , SocketStreamTest>setUp sends connectTo:port: which will end up using the standard timeout and may raise an exception; but the test code then explicitly does some wait method (which actually re-runs the very same lower-level code and may raise the same exceptions!) and other stuff. That looks to me like out of date code that will fail oddly with current Socket code. Tests and other examples really ought to be up to date and correct so we can rely upon them to work and to explain how to Do It Right.

In fact, the Socket test setup is not failing.  It's simply that you
need to give it some more thought, maybe step through the method,
write a Sockets program or look at an existing one.

Then, I think, all of your questions will be answered.

> As I say, I really don’t know Sockets. If someone loves Sockets and feels like fixing them up, I’d suggest starting by looking at senders of #connectTo:port: and spreading out from there. And maybe you could wave your hand and volunteer to help me out...

Funny!  Okay, I'll get right on that!  :)

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> M$ are grinning pigs in a sea of buggy code - The Inquirer
>

On 27-02-2014, at 10:47 AM, Chris Muller <[hidden email]> wrote:

> Your note is amusing.  Saying an exception is not handled, but not
> saying what should be done by the handler.  Simultaneously admitting
> not knowing about sockets and criticizing its "up-to-dateness".  I
> guess you mean correctness.

No, I mean that I looked a socket code to try to find examples to help me understand how they might have changed since the ancient scratch code I need to update, found that the #connect… methods now appear to include what used to be in the #waitForConn… type methods and then tried a bit of test code that seems not to be using the newer system.

Since the newer code raises exceptions from the #connect… rather than simply setting the socket status, the test code opens a degugger. Now maybe some other test code in the unit test stuff does indeed handle the exception but I didn’t spot it. And the point remains that doing
socket connect….
socket waitUntil….
will potentially do the wait timeout twice which seems unlikely to be what is wanted.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Suffers from Clue Deficit Disorder.

> No, I mean that I looked a socket code to try to find examples to help me understand how they might have changed since the ancient scratch code I need to update, found that the #connect… methods now appear to include what used to be in the #waitForConn… type methods and then tried a bit of test code that seems not to be using the newer system.
>
> Since the newer code raises exceptions from the #connect… rather than simply setting the socket status, the test code opens a degugger. Now maybe some other test code in the unit test stuff does indeed handle the exception but I didn’t spot it. And the point remains that doing
> socket connect….
> socket waitUntil….
> will potentially do the wait timeout twice which seems unlikely to be what is wanted.

I assume that test code is testing a network-failure situation then?
So you just need to handle those exceptions for that test.  It's
definitely an improvement over setting socket status, but I do think
this expression:

self
waitForConnectionFor: timeout
ifTimedOut: [ConnectionTimedOut signal: 'Failed to connect in ',
timeout asString, ' seconds']
ifRefused: [ConnectionRefused signal: 'Failed to connect in ', timeout
asString, ' seconds']

is duplicated too much; they should all be calling
#waitForConnectionFor: instead.