Библиотека Go для собеса | вопросы с собеседований

💬 Какие могут быть побочные эффекты от именованных параметров результата функции?



◆ Именованные параметры результата могут оказаться полезны в некоторых ситуациях, но поскольку их инициализация происходит с присваиванием им нулевого значения, то их применение иногда может привести к малозаметным багам.



🤔 Что не так с этим кодом?

func (l loc) getCoordinates(ctx context.Context, address string) (

    lat, lng float32, err error) {

    isValid := l.validateAddress(address)

    if !isValid {

        return 0, 0, errors.New("invalid address")}

    if ctx.Err() != nil {

        return 0, 0, err

    }

}

◆ На первый взгляд ошибка может быть неочевидной. Ошибка, возвращаемая в области видимости if ctx.Err() != nil, — это err. Но мы не присвоили переменной err никакого значения. Ей по-прежнему присвоено nil. Следовательно, этот код всегда будет возвращать ошибку nil.



◆ Код скомпилируется, потому что err была инициализирована нулевым значением благодаря именованным параметрам результата. Без присвоения имени мы получили бы ошибку компиляции:

Unresolved reference 'err'

◆ Один из возможных выходов — сделать переменную err равной ctx.Err():

if err := ctx.Err(); err != nil {

   return 0, 0, err

}

◆ Мы продолжаем возвращать err, но сначала присваиваем ей результат ctx.Err(). Обратите внимание, что err в этом примере затеняет переменную результата.



◆ Важно помнить, что каждый такой параметр инициализируется своим нулевым значением.



◆ Другой вариант — использовать пустой оператор return:

if err = ctx.Err(); err != nil {

    return 

}

◆ Но при этом нарушается правило о том, что не нужно смешивать в одном фрагменте кода пустые операторы return с такими же операторами, но с аргументами.



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