net: expose context Canceled/DeadlineExceeded error

[pascaldekloe]

Issue #28529 could be solved with the new error wrapping now.

What did you do?

Check for context.Canceled with errors.Is seems reasonable.

https://play.golang.org/p/-JTEZXGyfQ6

$ go version
go version go1.13.5 darwin/amd64

[dmitshur]

Thanks for making this issue.

Can you elaborate on what problem it would help solve to expose this information? What is it that cannot be done (or can be done, but inconveniently) before this is resolved, and how will it be done after?

/cc @mikioh @bradfitz @ianlancetaylor

Also /cc @bcmills who commented on the relevant issue #28529.

[pascaldekloe]

Generally speaking you want to continue the abort (by returning context.Canceled) if the context expired. Dial errors on the other hand must be reported [logged]. Maybe a retry or two?

[bcmills]

@pascaldekloe, that doesn't really answer @dmitshur's questions.

[pascaldekloe]

Yes it does @bcmills. You always block my issues with the WaitingForInfo label for some reason. Not helping at all.

[ianlancetaylor]

I believe the point here is to permit using error.Is(err, context.Canceled) on the error returned by net.Dial to see if the Dial failed because the context was canceled. That doesn't work today because of the mapErr function in net/net.go (https://golang.org/src/net/net.go?#L413) which changes context.Canceled to the net package internal error errCanceled. This was done when DialContext was introduced so that the net package operations would continue returning the errors that they always returned. That is because when DialContext was introduced, the existing DialTimeout function was changed to use a context. Changing the error from the internal errCanceled to context.Canceled would certainly break some tests and possible break some real code as well.

So this issue is basically: drop mapErr.

[pascaldekloe]

I'm stuck again on the same subject a year later. Would a change request help (to see what the change implies)?

[ianlancetaylor]

Thanks, I think we understand the code change, what we don't understand is what existing code would break if we make this change.

[pascaldekloe]

The net.errCanceled mapping is not exported, and its type errors.errorString has no properties other than the textual content. I believe this leaves 4 ways to act upon the error now.

(1) if err.Error() == "dial tcp: operation was canceled"
(2) if err.(*net.OpError).Error() == "operation was canceled"
(3) if strings.Contains(err.Error(), anySubstring("dial tcp: operation was canceled")
(4) if strings.Contains(err.(*net.OpError).Error(), anySubstring("operation was canceled")

If we'd replace net.errCanceled with fmt.Errorf("operation was canceled: %w", ctx.Err()), then only (1) and (2) would break.

Go has issues with exposing errors, i.e. net.ErrClosed, which sometimes forces coders into the practice of string matching. Do we really need compatibility for exact string matching too? That'd be support for bad practice on dubious practice, no?

The respective func mapErr notes // TODO(bradfitz): get rid of this after adjusting tests and making context.DeadlineExceeded implement net.Error?.

[ianlancetaylor]

We know that people do string matching on error strings, and in the past we've decided to not change error strings because doing so broke too much existing code. Yes, matching on error strings is typically bad practice. Still, we want to be careful in this area.

This particular change may be perfectly fine. As I said, we don't what existing code would break if we made the change. Maybe none.

[jayschwa]

Perhaps the error could remain the same but have an Is(target error) bool function added that returns true for the relevant context error.