net: Dial should not conceal effective errors #18183
Open
Milestone
Comments
If your only choices are "return the first error" and "return the last error", then the first is usually better. Say that a user has IPv4-only Internet access, and encounters a period of packet loss. I agree that returning all errors is the ideal solution, but at some point that list still needs to be reduced to a single human-readable error message. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://go-review.googlesource.com/8768 changed to return the first detected error on consecutive or parallel dialing as opposed to the previous. Unfortunately this change makes debugging hard. Also it probably makes package developers using the net package confusing.
For example, assuming we need to fetch some resource from golang.org on the node which has IP dual stack functionality and IPv4-only connectivity to golang.org, the current implementation returns an error regarding IPv6 transport even when the IPv4 connectivity is lost in the middle of the path.
I guess that there are two options; a) returning all detected errors by either a nested OpError or new error type in OpError when the connection setup function fails, b) returning the most effective error by referring to information on IP routing and forwarding.
I'd prefer the former. @pmarks-net, What do you think?
The text was updated successfully, but these errors were encountered: