ВС
обычный array literal
Size: a a a
2020 December 08
SP
PIN_Key_Index []TEXT,
ВС
TEXT[] по-моему
SS
по ссылке выше кто угодно может прийти
Спасибо)
H
Возможно.
H
Но у меня есть подозрение, что вы что-то не очень правильное делаете.
Д
Не отрициаю, но если коротко на данный момент есть структура в которой мне нужно проверить что десериализация из json приходит без пустых полей, а в решенни уже реализован универсальная функция которая принимает interface{} и возвращает новый
По задумке сейчас в него должен упасть *string или *int пройти проверку на nil, а на выход получить уже зачение
По задумке сейчас в него должен упасть *string или *int пройти проверку на nil, а на выход получить уже зачение
М
Возвращаясь к нашим баранам:
Есть функция, она что-то делает и возвращает тип данных User, который представляет из себя struct.
При этом структура содержит поля, которые ее не позволяют сравнивать.
Как элегантно решается история с успешным возвращением или неуспешным?
Насколько я понимаю, поскольку структуру сравнить нельзя, то единственным вариантом является что-то вроде:
Но элегантным этот способ не назвать. Может есть какой-то типовой набор кейсов на подобные случаи жизни?
Есть функция, она что-то делает и возвращает тип данных User, который представляет из себя struct.
При этом структура содержит поля, которые ее не позволяют сравнивать.
Как элегантно решается история с успешным возвращением или неуспешным?
Насколько я понимаю, поскольку структуру сравнить нельзя, то единственным вариантом является что-то вроде:
user:= someFunc...
if user.someP == nil {
//функция ничего не вернула потому что ничего не нашла
}
Но элегантным этот способ не назвать. Может есть какой-то типовой набор кейсов на подобные случаи жизни?
Пока пришел к варианту такому:
Вместо:
возвращать:
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Вместо:
func GetUser(id int) (SomeType, error)
возвращать:
func GetUser(id int) ( []SomeType, error)
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
ВС
а не проще вернуть в 1 случае ошибку, что пользователь не найден
G
Пока пришел к варианту такому:
Вместо:
возвращать:
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Вместо:
func GetUser(id int) (SomeType, error)
возвращать:
func GetUser(id int) ( []SomeType, error)
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Чем не подошло
func GetUser(id int) (*SomeType, error)
?
nil если юзера нетМ
Чем не подошло
func GetUser(id int) (*SomeType, error)
?
nil если юзера нетЯ их побаиваюсь)
М
В одной книге по голангу написано, что если не уверены, то не используйте указатели.
H
В одной книге по голангу написано, что если не уверены, то не используйте указатели.
проблем кучу обретают от бездумного использования их
G
Я их побаиваюсь)
Я обычно возвращаю кастомную ошибку, на которую можно сравнить, если не нашлось чегото в базе и потом в вышестоящем слое её обрабатываю. Например апи 404 вернёт.
DP
Пока пришел к варианту такому:
Вместо:
возвращать:
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Вместо:
func GetUser(id int) (SomeType, error)
возвращать:
func GetUser(id int) ( []SomeType, error)
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
а почему не
эффект тот же, а накладных расходов меньше
func GetUser(id int) (*SomeType, error)эффект тот же, а накладных расходов меньше