Thread by @GeePawHill

In re: exceptions in Java. I used SocketServer.accept() the other day. Now, for the unwashed, accept() is a blocking function in an async environment. It's for listening to see if someone connects to the listening port.

And what if -- I did -- you want to listen for this, but in an exitable way, so that, say, if no one connects for a second, you regain control and can do something else, for instance.

Here's how you do that:

try {
serversocket.setTimeOut(xxx)
serversocket.accept()
}
catch(SocketTimeoutException ignore) { }

Yes, that's correct. Yes, that is the intended usage. Set a timeout with one call, accept with another, wrap it in try-catch.

And I have to say I can't think of any possible reason that use case was designed that way.

You understand? The accept call *blocks*. It's not like we were doing anything else while it's running. We have no choice but to wait for its return.

I can think of at least 5 ways to cleanly implement ServerSocket.accept(xxx) and return a value to indicate that the xxx ran out and we didn't get any connections.

And they chose to throw an exception for that case.

I think it's because some Platonist somewhere thought, "it says exception, and you normally don't want to timeout the accept, cuz it's after all a blocking call, so I guess we'd better throw an exception".

(Side note: accept(), btw, doesn't mean "start listening". The ServerSocket starts listening when it's created. It means, "gimme one thing you heard". ServerSockets have no open or start or such-like, they only have a close. Kickin' it old-school, I spoze.)