testing/iotest: add ErrReader

[caarlos0]

Abstract

Add a iotest.ErrReader io.Reader implementation that reads 0 bytes and fails.

This would be useful for quickly adding test cases for when Read doesn't work for some reason.

Background

The iotest package already have a couple of other io.Reader implementations, but we don't have any that fails right away.

On nearly all codebases I worked in, I created this same failReader/errReader implementation. Judging by this and this github searches, I'm not alone.

Proposal

Add it to the standard library, under the iotest package.

I actually have the PR opened already: #34741

Rationale

Make it easier to add test cases for read failures.

[rsc]

I'd call it ErrReader, to match DataErrReader, but this seems fine to me.
That is:

package iotest

// ErrReader returns an io.Reader that returns 0, err from all Read calls.
func ErrReader(err error) io.Reader

[caarlos0]

ErrReader sounds good to me as well. Updated the proposal.

EDIT: updated PR as well.

[rsc]

Adding to proposal minutes. Seems fine to me, as I said before.

[rsc]

Based on how trivial this is and the lack of any objections, this seems like a likely accept.

[rsc]

No change in consensus, so accepted.

[networkimprov]

I think the "help wanted" tag got mangled?

[ianlancetaylor]

@networkimprov Thanks, fixed.

[caarlos0]

Do I need to do anything else here to get #34741 merged?

[psampaz]

This is a very useful addition in the stdlib.

I was wondering why this has to fail immediately and return 0 bytes read?

If the number of bytes read is set during the tests, ErrReader could potentially cover more cases
including the case of immediate failure using ErrReader(0)

Example:

func ErrReader(n int) io.Reader {
	return &errReader{n}
}

type errReader struct{
       n int
}

func (r *errReader) Read(p []byte) (int, error) {
	return n, ErrIO
}

@caarlos0 does it make sense?

[caarlos0]

@caarlos0 does it make sense?

sounds good to me, not sure if it can be changed now, since it was approved as-is... cc/ @rsc

[ianlancetaylor]

@caarlos0 You don't need to do anything at the moment. We are currently in a release freeze for 1.15. After the 1.15 release goes out, we can review the CL. Thanks for sending it.

Personally I think we should stick with the simple ErrReader. There are an infinite number of possible permutations; we don't want to support all of them.

[gopherbot]

Change https://golang.org/cl/199501 mentions this issue: testing/iotest: adds ErrReader

[gopherbot]

Change https://golang.org/cl/248898 mentions this issue: testing/iotest: correct ErrReader signature and remove exported error

[gopherbot]

Change https://golang.org/cl/249037 mentions this issue: net/http: use iotest.ErrReader on tests

[gopherbot]

Change https://golang.org/cl/285673 mentions this issue: doc/go1.16: mention new testing/iotest functions