search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.16k stars 17.69k forks source link

net: Dial should not conceal effective errors #18183

Open mikioh opened 7 years ago

mikioh commented 7 years ago

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?

pmarks-net commented 7 years ago

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. Dial tries IPv4 (which times out) followed by IPv6 (network unreachable). Displaying the last error leads to "IPv6 broke my Internet connection! How do I disable IPv6?"

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.

ashmeenkaur commented 2 months ago

+1 to returning all detected errors by either a nested OpError or new error type in OpError when the connection setup function fails.

Returning only the first detected error makes debugging hard.