Errors that returned by most of functions can hide issues communicated in HTTP API responses

[zhucebuliaolongchuan]

Errors that returned by most of function are actually return the error that raised by the internal function that actually would not fail for most of the times. The http.response return value actually carry some information such as > 300 response code which absolutely indicate some problems, but the error value would be nil most of times.

For example, I try to add the same vhost for multiple times, but the function would not return any error. But the response body indicate that the http.StatusCode is >300, which is not a expected status. And most of the function has the same problem, such as add user operation. What's more, even though you use random string as username and random string as password, you can actually establish the connection and can do everything without any returned error, but obviously the function would do nothing. So to this extend, the error value that returned by most operations seems useless since they are always nil.

The current solution to make our programs that using your repo work is to capture the http status code of the http response. But it barely indicate any problem. We could not know the real reason if the program fail, since error value is always nil.

[michaelklishin]

Returning an HTTP response or status code would help in some scenarios but it would be completely useless in others. If hostname resolution or TCP connection fails, there would be no HTTP response to return.

@zhucebuliaolongchuan given that returning an HTTP response is not something I'd be interested in doing, what alternatives do we have that would make this client work better for the scenarios you've outlined? I don't see a specific proposal in this issue, only a complaint.

[beetahnator]

@michaelklishin PR for catching bad credentials #145