Fix: we should be able to handle a "null" result from a server

[rwols]

If there's an error response, handle that.
Otherwise, handle the result.

[coveralls]

Coverage increased (+0.04%) to 28.259% when pulling 9a5262f on bugfix/handle-none-result into 03acb77 on master.

[tomv564]

Great to have more tests!
I'm a bit nervous that we're now moving to a 3rd way of handling responses instead of reverting to the original result/error checking.
Especially since it wasn't needed to get your memory leak fix in place?
If we continue with this logic, why did we drop the "invalid response payload" case?

[rwols]

If we continue with this logic, why did we drop the "invalid response payload" case?

the logic seemed somewhat complex:

no error key, no result key ==> invalid response
error key, no result key ==> handle error
no error key, result key ==> handle result
error key, result key ==> invalid response

I thought: If there's an error key present we should handle it regardless of the result key. Because of that, it turned out that the "invalid response" logical path went away.

Especially since it wasn't needed to get your memory leak fix in place?

You're right, I've reverted to the old behavior and added unit tests for that behavior.

[tomv564]

Thanks for the quick fix!