But I was wondering if in this case it is safe not to treat err and ignore it since the r *http.Request variable is supposed to be in memory and not on the hard disk and therefore, for example, will not be denied permission to read it and therefore ioutil.ReadAll will never return an error.
Indeed, ignoring an error saves three lines of code, but what I mean is, what do you win by saving three lines?
If this was my code, I would simply go ahead and add the error handling. Reasons:
I would not have to use brain energy for working out if this one particular error handling may be unnecessary. (Yes, I have a lazy brain.)
The code would be prepared to catch errors that I do not expect.
If the internal functionality of the callee changes, it may have more reasons than before to return an error. My code would automatically be prepared for that.
If I change the code to a call that is more likely to return an error, I cannot forget to add error handling (because it is already there). (Yes, I am forgetful at times.)
To return to your original question, I agree it should be unlikely, if not even impossible, that ReadAll(r.Body) returns an error. It seems that an http.Requestexpects to receive a body of either bytes.Buffer, bytes.Reader, strings.Reader, or struct noBody type, all of which should indeed provide error-free reading experience, except maybe for io.EOF, which ReadAllturns into a nil error.
For server requests, the Request Body is always non-nil
but will return EOF immediately when no body is present.
It should do well, except in a few special circumstances; e.g., when there’s a memory limit on the goroutine handling the request, and the request body is just too large.