On Tue, Feb 13, 2018 at 5:26 PM, Axel Wagner <axel.wagner...@googlemail.com> wrote:
> 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 > net.Conn. > 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 > it. > 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 > correctly. > 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. // Patrik -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
