On Tue, Feb 13, 2018 at 5:26 PM, Axel Wagner <axel.wagner...@googlemail.com>
> Not very, but it does depend on the details. For example, you might
> provide your own http.Transport for the client to use, or even your own
Using ioutils.ReadAll() on a HTTP request means to me to read out the
response's body. I cannot see how http.Transport and net.Conn would have
anything to do with this.
> You might have the server stop sending any data, so eventually the
> connection will timeout.
So what you're saying is that unless the response contain chunked data,
ioutil.ReadAll() will never fail?
> The question is, though, why would you want that?
As ioutil.ReadAll does return an error in its signature, i think it's good
form to test it. Don't you?
> Is that actually a path that is worth testing? Personally, I kind of doubt
That's kind of it really, i am having a hard time making up my mind here.
That's why i come for the golang nuts wisdom.
> You'll probably get more bang for your buck, if you instead send back
> broken/incomplete data from the server and see if the client handles that
I already test for this kind of problems in my unittests. It's more a
matter of what to do with the error return value from ioutil.ReadAll() when
i cannot see how i could ever get anything but err == nil. It might just be
me, that doesn't know enough about the ioutil.ReadAll() internals.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.