net: expose original context Canceled/DeadlineExceeded error

[ifraixedes]

My apologies if this is already reported however, I haven't been able to find something about in the issue tracker.

What version of Go are you using (go version)?

Go 1.10.4

Does this issue reproduce with the latest release?

I believe that I would have the same problem in Go 1.11.1 (as far as I can see in the sources of the master branch of this mirror repository)

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN="/go/bin"
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/root/apps/go"
GOTMPDIR=""
GOTOOLDIR="/root/apps/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build649898996=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Mostly, if I call net/Dialer.DialContext and the passed context is canceled, I cannot compare the error wrapped by net.OpError (Err attribute) with context.Canceled variable in order to distinguish this error of any other.

Why?

Because net/Dialer.DialContext calls dialSerial which in case that the context is canceled, it replaces the context.Canceled by an unexported error before assigning to net.OpError.Err (carried by the unexported function mapErr)

The same happens with the context.DeadlineExceeded

What did you expect to see?

Have the original context error in the OpError.Err attribute.

What did you see instead?

What I've described above, but I cannot simply figure it out if the error returned is one of the ones returned by context.

[bcmills]

Could you add some more detail about why you need the net package to distinguish these? In most cases I've encountered where I want to change behavior based on whether the Context was cancelled (e.g. by suppressing log messages for things that were intentionally cancelled), it has sufficed to write something like:

	conn, err := net.DialContext(ctx, network, addr)
	if err != nil {
		if ctx.Err() != context.Canceled {
			log.Printf([…])
		}
		return […]
	}
	[…]

More generally, I've found that it's useful for functions that may involve retries and backoff to return the last real error they encountered, rather than just a Canceled or DeadlineExceeded error: that way, if the call blocks due to some other issue (e.g. a persistent DNS issue), the program can report the actual issue (e.g. the DNS error) rather than a secondary symptom of it (e.g. a dial timeout).

[ifraixedes]

Could you add some more detail about why you need the net package to distinguish these? In most cases I've encountered where I want to change behavior based on whether the Context was cancelled (e.g. by suppressing log messages for things that were intentionally cancelled), it has sufficed to write something like:

I didn't think that I could have checked it in such way and I was probably looking for a way of doing so with the returned error, considering that the context cancelations errors are returned but remapped.

Such way works for what I need.

More generally, I've found that it's useful for functions that may involve retries and backoff to return the last real error they encountered, rather than just a Canceled or DeadlineExceeded error: that way, if the call blocks due to some other issue (e.g. a persistent DNS issue), the program can report the actual issue (e.g. the DNS error) rather than a secondary symptom of it (e.g. a dial timeout).

It makes sense to me.

I'm closing the issue.
Many thanks!

P.S. I've updated the links to the source of the opening comment to link to the last commit that I've just found in master for avoiding that links move around the source from time to time when master get updated and the issue can keep the context for any future reference.