Behavour of initial connect()

[peterhinch]

@kevinkk525 You earlier mentioned the behaviour of the initial connect(). If I understand you correctly, there are circumstances in which it can block indefinitely. If this can ever occur it will prevent .bad_wifi() from running so the user has no chance of fixing the situation.

If the above is correct, I think we should get rid of it. I'll document the behaviour and invite users to issue connect() in their bad_wifi() implementation.

[kevinkk525]

I experienced that problem at the beginning when my configuration was wrong, either ip or port because I forgot to change your values. Since I pulled the latest changes since 1.9.4. it does behave differently and ECONNABORTED and ECONNRESET are raised. For me this means there should be no way that connect blocks indefinitely and has been fixed. I don't think we should care about "backporting" the library to a version that is (hopefully) soon outdated. At least I hope that the new micropython version will be released before the library is finished.

[peterhinch]

If connect() can now raise an exception we need to change the code around both its calls, don't you agree?

[kevinkk525]

Yes I agree. Now that we have exceptions, we can implement those directly. Would you make a difference between an unreachable host and just a wrong port? unreachable host could be a wrong configuration (or server restart) while a wrong port could be that the server is not running, restarting or the port configuration is wrong but the ip configuration might be right. On the other hand it makes the library complex and the user has to check his configuration anyway.