Hi,
I'm pretty sure little or none of this is particularly new but I haven't
had much luck finding the canonical references. I guess it's the age-old
conversation about mechanical error checking vs backwards compatibility.
Here are three ugly corner cases which I've bumped into recently:
1- return fmt.Errorf("net/http: HTTP/1.x transport connection broken: %v",
err)
https://github.com/golang/go/blob/master/src/net/http/transport.go#L1651
Obviously, there's no shortage of cases like this in the standard library.
Squashing the error means that the caller has to dissect the resulting
string. Is it planned that cases like this in the standard library will be
moved from %v->%w?
2- var ErrTimeout error = &TimeoutError{}
https://github.com/golang/go/blob/master/src/internal/poll/fd.go#L37
Even though ErrTimeout looks exported, it's in an internal package so a
caller can't import the package and check equivalence against the error.
Again, caller has to dissect the resulting string.
3- type tlsHandshakeTimeoutError struct{}
https://github.com/golang/go/blob/master/src/net/http/transport.go#L2427
Not exported; again, caller has to dissect the resulting string.
Assuming that %v->%w is the answer for case 1 -- can anything be done to
help cases 2 and 3?
Cheers,
Jim
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
