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.