The reason for deprecating Temporary is that the set of "temporary" errors 
was extremely ill-defined. The initial issue for https://go.dev/issue/45729 
discusses the de facto definition of Temporary and the confusion resulting 
from it.

Perhaps there's a useful definition of temporary or retriable errors, 
perhaps limited in scope to syscall errors such as EINTR and EMFILE. I 
don't know what that definition is, but perhaps we should come up with one 
and add an os.ErrTemporary or some such. I don't think leaving 
net.Error.Temporary undeprecated was the right choice, however; the need 
for a good way to identify transient system errors such as EMFILE doesn't 
mean that it was a good way to do so or could ever be made into one.

On Wednesday, April 20, 2022 at 6:02:34 PM UTC-7 ces...@gmail.com wrote:

> In Go 1.18 net.Error.Temporary was deprecated (see
> https://go.dev/issue/45729). However, in trying to remove it from my
> code, I found one way in which Temporary is used for which there is no
> obvious replacement: in a TCP server's Accept loop, when deciding
> whether to wait and retry an Accept error.
>
> You can see an example of this in net/http.Server today:
>
> https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059
>
> In this case, Temporary seems useful, and enumerating the OS-specific
> errors myself doesn't seem like a good idea.
>
> Does anyone have a good solution here? It doesn't seem like this was
> adequately considered when making this deprecation decision.
>
> Caleb
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1024e668-795f-454f-a659-ab5a4bf9517cn%40googlegroups.com.

Reply via email to