Poor connection maintenance and exception strategy in `JsonRpcClient`

[dikderoy]

trafficstars

currently lib takes no actual care and does not really "knows" whatever connection is alive, also it has very poor interface to inform user of such problem. handling connection recovery becomes a mess.

If connection becomes a mess, first we could receive something from the depths of aiohttp and asyncio such as RuntimeError("Transport closed..."),

if we try to connect to nonexisting host (name not resolved) we receive:

aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host [Name or service not known]

at first, but when comes the worst, after an unsuccessful attempt to connect JsonRpcClient object is left in such state what it does not tries to autoconnect and instead throws:

 AttributeError: 'NoneType' object has no attribute 'send_str'

because attribute _ws is not dropped upon previous connection failure.

Please consider making consistent exception strategy and try not to leave objects in non recoverable state. Taming such interface is a pain.

[fscherf]

hi @dikderoy,

first of all: Thanks for testing and contributing! I know the client library is full of flaws because it was never meant to be an end user api but a simple testing tool for unittests. All code that made it more user friendly was contributed by users who are interessted in the client side of json rpc.

For me only the server side is interesting because all of my projects that use the rpc use a webbrowser as client. There may projects in the future that require a more capable python-client but until then i wont have time to invest in this api.

But there is always time for review! If you send patches for the client or even a better over all design i will review and merge as soon as possible.