G
а почему не
эффект тот же, а накладных расходов меньше
func GetUser(id int) (*SomeType, error)эффект тот же, а накладных расходов меньше
Боится он их, в книжке вычитал что плохо...
Size: a a a
2020 December 08
G
В одной книге по голангу написано, что если не уверены, то не используйте указатели.
Да, но вот тут само то, а просто так их пихать не стоит, да
М
Боится он их, в книжке вычитал что плохо...
В книжке не написано, что плохо. Не надо придумывать. Там написано так, как я написал выше.
V
Пока пришел к варианту такому:
Вместо:
возвращать:
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Вместо:
func GetUser(id int) (SomeType, error)
возвращать:
func GetUser(id int) ( []SomeType, error)
Который уже и может быть nil, и поддается сравнению.
Мне кажется, это неплохое, масштабируемое решение
Ну это странно, что возвращается список, когда хочешь одного найти. И проверять будет сложнее
G
В книжке не написано, что плохо. Не надо придумывать. Там написано так, как я написал выше.
Если хочется совсем без указателей, посмотри на time.Time, там есть метод IsZero() bool, который true если тип неиницилизирован
H
Там выше советовали уже
IsValid() сделатьH
который по умолчанию
False и не надо мудрить с True в конструктореD
Подскажите, почему в джейсоне возвращается пустой массив как null?
G
Подскажите, почему в джейсоне возвращается пустой массив как null?
А массив в го иницилизирован? Он будет null пока не будет сделан make([]type, 0)
NL
Подскажите, почему в джейсоне возвращается пустой массив как null?
Потому что это скорее всего nil слайс
DP
Я их побаиваюсь)
но вот возвращать указатель в вашей ситуации - общепринятая практика.
М
В одной книге по голангу написано, что если не уверены, то не используйте указатели.
Как раз в вашем случае они нужны
AS
Чем не подошло
func GetUser(id int) (*SomeType, error)
?
nil если юзера нетну, ваще есть паттерн "nil object"
https://en.wikipedia.org/wiki/Null_object_pattern
иначе потом код превращается в сплошные проверки на nil
(но гоферам к таким проверкам, собсна, не привыкать)
https://en.wikipedia.org/wiki/Null_object_pattern
иначе потом код превращается в сплошные проверки на nil
(но гоферам к таким проверкам, собсна, не привыкать)
G
ну, ваще есть паттерн "nil object"
https://en.wikipedia.org/wiki/Null_object_pattern
иначе потом код превращается в сплошные проверки на nil
(но гоферам к таким проверкам, собсна, не привыкать)
https://en.wikipedia.org/wiki/Null_object_pattern
иначе потом код превращается в сплошные проверки на nil
(но гоферам к таким проверкам, собсна, не привыкать)
не, ну то есть возврат одной записи как []SomeType с последующей проверкой на nil тебя устраивает больше?) У себя я возвращаю кастомную ошибку если элемента нет, но да, со звёздочкой, всёравно)
AS
не, ну то есть возврат одной записи как []SomeType с последующей проверкой на nil тебя устраивает больше?) У себя я возвращаю кастомную ошибку если элемента нет, но да, со звёздочкой, всёравно)
не, я этого не говорил
AS
в таких случаях имеет смысл сделать исходящую сигнатуру вида
такой интерфейс хорошо подходит, если не хочется копаться в ошибке и создавать протечки в абстракциях чтобы понять был ли объект не найден или что еще произошло
(User, bool, error), где bool - флаг обозначающий был ли объект найдентакой интерфейс хорошо подходит, если не хочется копаться в ошибке и создавать протечки в абстракциях чтобы понять был ли объект не найден или что еще произошло
АД
в таких случаях имеет смысл сделать исходящую сигнатуру вида
такой интерфейс хорошо подходит, если не хочется копаться в ошибке и создавать протечки в абстракциях чтобы понять был ли объект не найден или что еще произошло
(User, bool, error), где bool - флаг обозначающий был ли объект найдентакой интерфейс хорошо подходит, если не хочется копаться в ошибке и создавать протечки в абстракциях чтобы понять был ли объект не найден или что еще произошло
насколько огромна разница между?
if exist и if errors.Is(err, ErrNotFound)?