How to reliably detect if an UDPConn is closed?

<p>Hi gophers!</p> <p>I&#39;m trying to detect, reliably, if an UDPConn is closed, when I receive an error from <code>WriteTo()</code> function. The error.Error() has the suffix <code>use of closed network connection</code> so I can check for that suffix in the error message, but it doesn&#39;t feel reliable at all (but maybe that&#39;s the convention).</p> <p>Thanks!</p> <hr/>**评论：**<br/><br/>Jelterminator: <pre><p>As far as I know this only works when sending UDP to localhost (maybe addresses pointing to your current machine as well). </p> <p>Otherwise you cannot detect if a UDP connection is closed, mainly because there&#39;s not really such a thing as a UDP connection. UDP is a fire and forget protocol. You send a message and expect nothing back. UDP just defines what the packet should look like. If the other end happens to be listening on the port then it will do something, otherwise not.</p></pre>boramalper: <pre><p>Totally, but you can still <a href="https://golang.org/pkg/net/#UDPConn.Close" rel="nofollow"><code>Close()</code></a> a <a href="https://golang.org/pkg/net/#UDPConn" rel="nofollow">UDPConn</a> and any <code>ReadFrom()</code> &amp; <code>WriteTo()</code> operation return an error, as in my case.</p></pre>tscs37: <pre><p>that&#39;s because Close() will close the underlying socket on the operating system.</p> <p>Close() does not do anything about the UDP protocol, the other side could still be happily firing UDP packets in your direction or someone else could even fake your packets and continue firing packets to the other side or a number of other things.</p> <p>UDPConn is merely an open socket that points to some remote address, nobody on the internet or your computer actually cares what happens after it leaves your Ethernet connection.</p></pre>Jelterminator: <pre><p>Ok, that makes more sense then. </p> <p>In another comment I see you want to use the error to signal stopping of the program/transfer. This seems like a bad and error prone way to do it though. Only using the error of ReadFrom or WriteTo to check if the program should stop is not a good way to go. It could just as well be closed by the OS for some reason. You should signal stopping of the program/transfer by using a channel.</p></pre>boramalper: <pre><p>Alright, thanks! :)</p></pre>icholy: <pre><p>What are the alternative error conditions?</p></pre>boramalper: <pre><p>If you are asking for all other possible errors, I&#39;m using the standard <code>net</code> package. Else if you are asking for what other errors do I care about specifically, I don&#39;t: the only kind of error I treat specially is &#34;use of closed network connection&#34; error.</p></pre>icholy: <pre><p>I&#39;m asking why you need to know that the connection is closed. Just treat an error as any indication that the connection is no longer usable.</p> <p>edit: take a look at <a href="https://golang.org/pkg/net/#Error" rel="nofollow">https://golang.org/pkg/net/#Error</a></p></pre>boramalper: <pre><p>Ah okay! I have a goroutine reading from the socket and I close socket as a way to stop the goroutine without introducing a termination/stopping channel. So I care about why the error occurred. </p></pre>theLRG: <pre><p><del>The error that&#39;s being passed to you is defined in the net package source code as an unexported variable errClosing. There was an issue opened <a href="https://github.com/golang/go/issues/4373" rel="nofollow">here</a> and a fix was committed for inclusion in 1.9 <a href="https://github.com/golang/go/commit/fb4b4342fe298fda640bfa74f24b7bd58519deba" rel="nofollow">here</a>. Basically, right now you need to check for the message string, but in 1.9 they will have net.ErrNetClosing for you to check.</del></p> <p>Edit: nope. See below.</p></pre>dchapes: <pre><blockquote> <p>but in 1.9 they will have net.ErrNetClosing for you to check.</p> </blockquote> <p>This is not true. The <code>ErrNetClosing</code> variable is in <code>internal/poll/fd.go</code> so it is inaccessible for comparison/testing by user code. User code sees an <code>*net.OpError</code> with an <code>Err</code> field set to a <code>*errors.errorString</code> value. All the commit you link to [effectively] does is revert a change to the text of that error to not break some code that was (incorrectly IMO) grokking around in errors strings to guess what the errors was. [Note, the change also does change the variable to an exported typed but the key detail is that it&#39;s exported from an internal/in-accessible package].</p></pre>boramalper: <pre><p>That&#39;s the kind of answer I was looking for, thanks a ton!</p></pre>