5 главных ошибок новичка в Go и как их избежать

Когда только начинаешь работать с Go, кажется, что все понятно и просто. Но потом внезапно оказывается, что горутины ведут себя странно, ошибки куда-то пропадают, а код работает не так, как ожидалось.

Знакомо? Не переживайте, я думаю, что через это проходят многие. Поэтому давайте разберем самые частые ошибки новичков в Go и научимся их обходить.

1. Игнорирование обработки ошибок (error)

Ошибка: Написать _ (нижнее подчеркивание) вместо переменной для ошибки. «Работает, да и ладно» — думаете вы, и код продолжает выполняться с потенциально сломанным состоянием.

// плохо
file, _ := os.Open("example.json")
defer file.Close()

// продолжаем работать с file, который может быть nil

Почему это плохо: В Go ошибки — это не исключения, это часть API. Игнорируя их, вы прячете голову в песок. Программа может «тихо» сломаться, и дебаг превращается в сплошное разочарование.

Как избежать:

Всегда обрабатывайте ошибки явно. Это не прихоть, а ваша страховка.

// хорошо
file, err := os.Open("example.json")
if err != nil {
    // обрабатываем ошибку
    log.Fatalf("Не удалось открыть файл: %v", file)
}

defer file.Close()

2. Непонимание работы с указателями и значениями

Ошибка: Непонимание, когда метод должен изменять оригинальную структуру, а когда работать с копией.

// плохо - метод не меняет оригинал 
// (получатель по значению)
func (u User) UpdateName(name string) {
    // изменяется копия
    u.Name = name
}

// плохо - метод меняет оригинал 
// (получатель по указателю) 
func (u *User) GetFullName() string {
    // указатель избыточен
    return u.FirstName + " " + u.LastName
}

Почему это плохо: В первом случае изменения не применяются к исходному объекту. Во втором — указатель используется там, где это не нужно.

Как избежать:

• Используйте указатели, когда нужно изменить исходный объект.
• Используйте значения, когда метод только читает данные.

 
// хорошо (меняем оригинал)
func (u *User) UpdateName(name string) {
    u.Name = name
}

// хорошо (только для чтения)
func (u User) GetFullName() string {
    return u.FirstName + " " + u.LastName
}

3. Проблемы с работой горутин и циклами

Ошибка: Классическая ловушка: использование переменной цикла внутри горутины.

// плохо
for _, element := range slice {
    go func() {
        // захватывает element
        fmt.Println(element)
    }()
}

Почему это плохо: Горутины запускаются асинхронно. К моменту их выполнения цикл, скорее всего, уже завершится, и все горутины будут ссылаться на одну и ту же ячейку памяти, в которой лежит последнее значение element.

Как избежать:

Передавайте переменную цикла как аргумента в анонимную функцию. Это создает копию значения для каждой горутины.

 
// хорошо
for _, element := range slice {
    go func(e int) {
        // работа с собственной копией
        fmt.Println(e)
    // явно передаем element как аргумент
    }(element)
}

4. Неправильное использование defer

Ошибка: Думать, что defer выполняется прямо в том месте, где он объявлен.

// плохо
file, err := os.Open("someFile.txt")
if err != nil {
    log.Fatal(err)
}
// file закроется после завершения функции
defer file.Close()
// долгие операции с file...

Почему это плохо: На самом деле, defer откладывает выполнение функции до выхода из текущей функции. Ошибка не в этом примере, а в непонимании контекста. Например, использование defer в цикле может привести к утечкам ресурсов, если вы ожидаете, что ресурс освободится сразу.

Как избежать:

Помните, что defer выполняется при выходе из функции, а не из блока. Для освобождения ресурсов в цикле иногда лучше обойтись без defer или вынести логику в отдельную функцию.

// хорошо
for _, filePath := range filePaths {
    err := func() error {
        f, err := os.Open(filePath)
        if err != nil {
            return err
        }
        // закроется при выходе из анонимной функции
        defer f.Close()
        return nil
    }()
    if err != nil {
        // обработка
    }
}

5. Борьба с системой типов вместо ее использования

Ошибка: Попытка обойти статическую типизацию через interface{} и приведение типов type assertion без необходимости.

// плохо (код становится хрупким и небезопасным)
var data interface{} = getSomeData()
if str, ok := data.(string); ok {
    // работа с str
} else {
    // ...
}

Почему это плохо: Вы теряете все преимущества компилятора Go. Ваш код становится подвержен ошибкам в рантайме, которые в Go с его строгой типизацией должны отваливаться на этапе компиляции.

Как избежать:

Проектируйте код, опираясь на интерфейсы. Создавайте небольшие, конкретные интерфейсы и используйте их.

 
// правильно
type Reader interface {
    Read() ([]byte, error)
}

func Process(r Reader) {
    data, err := r.Read()
    if err != nil {
        // ...
    }
    // ...
}
// теперь можно передать в Process любой объект, 
// который удовлетворяет интерфейсу Reader

А с какими ошибками вы уже успели «познакомиться» на собственном опыте? Делитесь в комментариях — обмен реальным опытом делает нас лучше.