-
Notifications
You must be signed in to change notification settings - Fork 18k
net: document potential values for the "Op" in net.OpError #36703
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Here's the list of
|
Great question, @kevinburkemeter |
I think that before listing the various options we should rationalize them. They seem to be a mix of operations like "dial" and system calls like "wsasend". What are we trying to tell the programmer? What do we expect them to do with this information? |
Change https://golang.org/cl/263557 mentions this issue: |
@ianlancetaylor I sent a CL; I figure at the very least we could document the current state of things; if they improve we can document the improvements. My motivation or rationalization was trying to figure out what part of the dial operation actually sent bytes to the remote server and whether I could determine what stage of the operation we were in based on the Op value. In theory I could use that to, for example, determine with 100% confidence that a Dial operation could be retried because the remote server did not receive any bytes of the request. |
My concern is that once we document the set of I would be fine with listing the various |
Could I link to this Github issue? Or to a page on the wiki? Are those temporary enough? |
I'm really sorry, now I've lost track of what we are talking about. I'm saying: before we officially document the list of values, let's rationalize them. Because right now they don't make a lot of sense to me (what is "announce"?). |
Could you clarify what you mean by "rationalize"? Aren't the Ops references to net APIs? The current values are part of the OpError API, even if not documented, so you can't change them. Why would you not document them? |
As far as I know there is no net API named If the values are not documented, then by definition they are not part of the API. Now, admittedly, they are part of the way that the current code works, and it is possible that changing them would break existing code. But I think that is fairly unlikely. At least, I think it is unlikely enough that we can at least consider changing the values where it makes sense. |
Returning the same constants in an exported type's field for 10y looks like API to me :-) But sure, rename "proxyconnect" to "dial:proxy" or somesuch; maybe no one will complain. |
The current documentation reads:
As far as I am aware the only way to determine which "Op"'s exist is by grepping the source code of the
net
package.In particular I am interested in determining whether an error with an
Op
value of"dial"
could have ever been returned after a client sent bytes of a request to a remote HTTP server.The text was updated successfully, but these errors were encountered: