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

Question

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

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

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

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

func (cn *conn) cancel() error

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

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

Answer 1

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

---

Первое правило: проверяйте ошибки.

---

func (cn *conn) cancel() error

Если я пишу

cn.cancel()

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

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

_ = cn.cancel()

, я не забуду проверитьошибок, и я решил сбросить значение ошибки.

---

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

Идентификатор пробела

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

Назначения

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

Answer 2

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

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

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