Catching "bind: address already in use"

I want to catch "bind: address already in use" error in golang.

conn, err := net.ListenUDP("udp", addr)
if err != nil {
    if CATCH_BIND_ERROR(err) {
         // Do something if 'addr' is already in use
    } else {
         panic(err)
    }
}

Is there any way to implement CATCH_BIND_ERROR function?

The easy way is just to check the text of the error:

conn, err := net.ListenUDP("udp", addr)
if err != nil && err.Error() == "bind: address already in use" {
    // Failed to bind, do something
}
if err != nil {
    // Some other error
    panic(err)
}

For a simple case like this, this may be sufficient. This approach is somewhat fragile, however:

1. If the library ever changes the error message (this does happen from time to time, although is probably unlikely in this specific instance), the check will break
2. If you do this check in some wrapping function, that may also return other types of errors, you may, at least in theory, receive a false positive, if some other functionality returns an error with the same text (also probably unlikely in this case)

To mitigate these concerns, you may be able to check for the specific error type, rather than just a textual representation. In your example, the net package provides a few custom errors. The ListenUDP method returns a net.OpError, which means you can examine it more closely. For example:

conn, err := net.ListenUDP("udp", addr)
var opErr net.OpError
if errors.As(err, &opErr) {
    if opErr.Op == "listen" && strings.Contains(opErr.Error.Error(), "address already in use") {
        // Failed to bind, do something
    }
}
if err != nil {
    // Some other error, panic
    panic(err)
}

Or prior to Go 1.13:

conn, err := net.ListenUDP("udp", addr)
if opErr, ok := err.(*net.OpError); ok {
    if opErr.Op == "listen" && strings.Contains(opErr.Error.Error(), "address already in use") {
        // Failed to bind, do something
    }
}
if err != nil {
    // Some other error, panic
    panic(err)
}

In this case, we still depend on a textual check, so there's still a risk of future library changes breaking the test. But by checking for the net.OpError type, we do mitigate the second risk, that some other error, with the same text, may be raised.