Присвоение возвращаемой ошибки подчеркиванию

Question

Я читал код Golang с github.com/lib/pq, который предоставляет драйверы для взаимодействия с базой данных postgres.

Среди кода я наткнулся на это:

go func() {
    select {
    case <-done:
        _ = cn.cancel()
        finished <- struct{}{}
    case <-finished:
    }
}()

Функция отмены выглядит так:

func (cn *conn) cancel() error

Насколько я могу судить, подчеркивание не используется в качестве статического утверждения о типе (и, следовательно, компилятор не оценивает какие-либо побочные эффекты, насколько я могу видеть ( как в этом примере)), и это не 't второй параметр, с помощью которого автор может отказаться от него.

Итак, зачем присваивать результат функции отмены (ошибка) подчеркиванию?

Answer 1

Код должен быть правильным. Чтобы быть уверенным в правильности кода, код должен быть читаемым.

---

Первое правило Go: проверка на ошибки.

---

func (cn *conn) cancel() error

Если я напишу

cn.cancel()

я забыл проверить ошибки или решил отказаться от значения ошибки?

Однако, если я напишу

_ = cn.cancel()

Я не забыл проверить ошибки и решил отказаться от значения ошибки.

---

Спецификация языка программирования Go

Пустой идентификатор

Пустой идентификатор представлен символом подчеркивания _. Он служит анонимным заполнителем вместо обычного (непустого) идентификатора и имеет особое значение в объявлениях, в качестве операнда и в присваиваниях.

Назначения

Пустой идентификатор позволяет игнорировать правые значения в присваивании:

Answer 2

Пустой идентификатор "_" является специальным анонимным идентификатором. При использовании в присваивании, как в этом случае, он позволяет явно игнорировать правые значения. Итак, разработчик решил игнорировать / отбросить ошибку, возвращаемую этим вызовом метода.

Несколько причин, почему они могли это сделать (основываясь на быстром взгляде на вызов метода и контекст, я думаю, 3 или 4):

1. Вызов метода гарантированно будет успешным в этом контексте.
2. Ошибка уже достаточно обработана в вызове метода; нет причин снова с этим справляться.
3. Ошибка не имеет значения (например, соответствующий процесс все равно завершится, и результат будет таким же, как если бы вызов метода прошел без ошибок).
4. Разработчик спешил заставить что-то работать, игнорировал ошибку, чтобы сэкономить время, а затем не смог вернуться и обработать ошибку.