💡Как тривиально проверить значения интерфейса на nil?

В Go новички часто сталкиваются с проблемой интерфейсных переменных, которым присваивается nil указатель. В таком случае, хотя значение в интерфейсе является nil, сама переменная интерфейса не равна nil.

Пример: создаем переменную x как указатель на int, который по умолчанию nil, и переменную y как пустой интерфейс, который тоже nil по умолчанию. После присваивания x переменной y, интерфейс y уже не является nil, хотя x все еще nil.

var x *int
var y any
y = x

📌 Что вернет y == nil?

Вернет false. Это потому, что интерфейс не просто представляет значение, которое ему присвоено, а действует как контейнер для этого значения.

Для проверки, является ли значение в интерфейсе nil, нужно использовать утверждение типа. Например, для проверки y на nil, используем:

y.(*int) == nil

Это показывает, что интерфейс y не nil, но содержащееся в нем значение — nil. Полный пример здесь.

#tip

🤔 Где искать библиотеки и инструменты для своих проектов?

🧰 Подборка для Go-разработчика:

🔗 pkg.go.dev

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

🔗 GitHub

Вводите в поисковую строку language:go + свой запрос и анализируете результаты.

🔗 Awesome Go

Один из самых старых и самых поддерживаемых кураторских списков по Go.

🔗 Libhunt.com

Коллекция Go-проектов, отфильтрованных по количеству упоминаний, звезд или другим критериям.

🔗 go-recipes

Тщательно подобранный список полезных Go-инструментов, разделенных на категориям.

#tip

🤔 Context vs структура: следует ли передавать информацию, специфичную для запроса, через context.Context?

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

❓Следует ли использовать этот механизм для передачи информации по цепочке вызовов запроса? Или лучше использовать обычную структуру?

Вот две причины, по которым использование Context для передачи значений может быть плохой идеей:

Значения в Context представляют собой пары ключ/значение, где ключ и значение являются пустыми интерфейсами (т. е. any). Другими словами, значения в контексте — это как мешок со всем подряд. Компилятор не может помочь вам отловить ошибки типов или даже проверить, есть ли информация. Удачи в устранении неполадок 😉

Если вы видите функцию, принимающую параметр Context, вы не можете сказать, что внутри. Если вы видите функцию, которая принимает параметр структуры, вы можете ясно видеть, что данные передаются, и что это за данные.

❓Но разве doSomething(ctx) не выглядит намного чище, чем doSomething(ctx, someStruct)?

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

❓Так context.WithValue() следует избегать?

Значения в контексте могут быть полезны, если они не критичны для бизнес-логики приложения. Например, совершенно нормально передавать идентификаторы запросов для логирования или измерения метрик. Читатель все равно сможет понять логику кода, и если что-то пойдет не так с этим идентификатором, это повлияет только на логирование или метрики приложения, но не на результат запроса.

💡Если данные важны для вашей бизнес-логики, не помещайте их в Context.

#tip

💡Как тривиально проверить значения интерфейса на nil?

В Go новички часто сталкиваются с проблемой интерфейсных переменных, которым присваивается nil указатель. В таком случае, хотя значение в интерфейсе является nil, сама переменная интерфейса не равна nil.

Пример: создаем переменную x как указатель на int, который по умолчанию nil, и переменную y как пустой интерфейс, который тоже nil по умолчанию. После присваивания x переменной y, интерфейс y уже не является nil, хотя x все еще nil.

var x *int
var y any
y = x

📌 Что вернет y == nil?

Вернет false. Это потому, что интерфейс не просто представляет значение, которое ему присвоено, а действует как контейнер для этого значения.

Для проверки, является ли значение в интерфейсе nil, нужно использовать утверждение типа. Например, для проверки y на nil, используем:

y.(*int) == nil

Это показывает, что интерфейс y не nil, но содержащееся в нем значение — nil. Полный пример здесь.

#tip

👩‍💻 Функция Join пакета errors конкатенирует список ошибок и возвращает ошибку, если хотя бы одна из переданных ошибок не nil.

Join возвращает nil, если все переданные ошибки равны nil.

#tip by Golangbot