In case of a non-
nil error return value, usually other parameters are left to the zero value of their type, which in case of
io.Reader (which is an interface type) should be
return nil, err
Callers are responsible to first always check the returned error, and only proceed to use other return values if the error is
nil. This is the general "rule". There may be exceptions of course, in which case you should document the deviant behavior.
Actually there's nothing wrong with providing other values along with non-
nil errors, and often it's useful. Typical example is the
io.Reader.Read() method, which documents how implementations should (must) work:
It returns the number of bytes read (0 <= n <= len(p)) and any error encountered.
... When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read.
So even if
Reader.Read() returns a non-
nil error, it also reports how many bytes it was able to read successfully before the error was encountered, so you may process / use up to
n bytes from the slice.