go: net: expose context Canceled/DeadlineExceeded error
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
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 13
- Comments: 15 (14 by maintainers)
Commits related to this issue
- Apply error string matching conform <https://github.com/golang/go/issues/36208>. — committed to pascaldekloe/mqtt by pascaldekloe 3 years ago
- Refactor providers/postgis to use pgx v4 * refactored providers/postgis to use the pgx4 client. Support for Postgres versions > 12 is now possible. * provider/postgis: Properly wrap errors in messag... — committed to go-spatial/tegola by iwpnd 2 years ago
- Refactor providers/postgis to use pgx v4 * refactored providers/postgis to use the pgx4 client. Support for Postgres versions > 12 is now possible. * provider/postgis: Properly wrap errors in messag... — committed to go-spatial/tegola by iwpnd 2 years ago
I believe the point here is to permit using
error.Is(err, context.Canceled)on the error returned bynet.Dialto see if theDialfailed because the context was canceled. That doesn’t work today because of themapErrfunction in net/net.go (https://golang.org/src/net/net.go?#L413) which changescontext.Canceledto the net package internal errorerrCanceled. This was done whenDialContextwas introduced so that the net package operations would continue returning the errors that they always returned. That is because whenDialContextwas introduced, the existingDialTimeoutfunction was changed to use a context. Changing the error from the internalerrCanceledtocontext.Canceledwould certainly break some tests and possible break some real code as well.So this issue is basically: drop
mapErr.Not quite, I was suggesting to implement
interface{ Is(error) bool }on the existing error so thaterrors.Is(err, context.SomeError)works. It looks like your proposed change will achieve the same effect though. 👍🏻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.
Perhaps the error could remain the same but have an
Is(target error) boolfunction added that returns true for the relevant context error.